Ein Überblick über Aufbau, Implementierung und zentrale Erkenntnisse von ASCEND
ASCEND verbindet die in der Praxis oft getrennten Bereiche Operational Technology (OT) und Information Technology (IT) in einem gemeinsamen Netzwerk. Ziel ist es, die Chancen und Risiken einer solchen Vernetzung sichtbar zu machen. Im OT-Teil wird ein Modellaufzug in einem dreigeschossigen Gebäude über eine Siemens S7-1200 SPS gesteuert. Das IT-Netz stellt eine Unternehmensumgebung mit zentraler Verwaltung, Firewalls und einem SIEM dar, während es gleichzeitig Zugriff auf das Aufzugsystem ermöglicht. Durch gezielte Angriffsszenarien werden Schwachstellen und die Bedeutung von Security in diesen Netzen aufgezeigt.
Ein dreigeschossiges Modellgebäude beherbergt einen vollständig funktionsfähigen Aufzug mit echter Steuerungstechnik. Die Siemens SIMATIC S7-1200 SPS übernimmt alle Fahrbewegungen, Türsteuerungen und Sicherheitslogiken via SCL und Motion-Control-Technologieobjekten. Reed-Sensoren liefern die Positionsdaten; ein webbasiertes HMI direkt auf der SPS ermöglicht die Bedienung über den Browser.
Zwei Unternehmensstandorte (DataCenter & Office) laufen auf einer Cisco UCS / VMware vSphere-Infrastruktur. Das Active Directory der Domain ascend.da.at verwaltet alle Benutzer, Gruppen und Rechte nach dem AGDLP-Prinzip. FortiGate HA-Firewalls schützen beide Standorte; ein FortiSIEM überwacht das gesamte Netzwerk in Echtzeit.
Zwei ISP-Router simulieren realistische Weitverkehrsverbindungen. ISP1 betreibt einen MPLS-Backbone mit OSPF als IGP und LDP für Label-basiertes Forwarding. ISP2 (AS 2122) ist intern als BGP Confederation organisiert, um das Full-Mesh-Erfordernis von iBGP zu umgehen. Zwischen den Standorten läuft ein IPsec Site-to-Site VPN über die FortiGates, authentifiziert per Pre-Shared Key.
Eine realistische 5-stufige Angriffskette zeigt, wie ein Angreifer vom Internet bis zur Aufzugssteuerung vordringen kann. Jeder Schritt wird vom FortiSIEM über Korrelationsregeln erkannt und als Incident geloggt. Gleichzeitig demonstriert die Infrastruktur Schutzmaßnahmen wie LAPS, Protected Users, NTLMv2-Erzwingung und einen gehärteten Jump Host.
Die Identitätsverwaltung von ASCEND basiert auf einer Single-Forest-Struktur unter der Domain ascend.da.at. Die Infrastruktur ist auf zwei Standorte (DataCenter und Office) verteilt. Drei Domain Controller stellen die Verfügbarkeit sicher, wobei die FSMO-Rollen auf DC1 (Schema und Domain Naming Master) und DC2 (RID, PDC Emulator und Infrastructure Master) aufgeteilt sind. Am Office-Standort kommt ein Read-Only Domain Controller (RODC) zum Einsatz, um die Sicherheit in einer physisch weniger geschützten Umgebung zu erhöhen.
Der Aufbau der Domain Controller wurde mittels Ansible-Playbooks über das WinRM-Protokoll automatisiert. Die anschließende Konfiguration der logischen Struktu und Services erfolgte primär durch PowerShell-Skripte, welche unter anderem den Import von Benutzern und Gruppen aus CSV-Dateien übernehmen. System-State-Backups sichern den Verzeichniszustand ab.
Ressourcenzugriffe werden nach dem AGDLP-Prinzip verwaltet: Benutzerkonten werden in Globalen Gruppen (z. B. IT, OT, HR) organisiert, welche wiederum in Domain Local Groups verschachtelt sind. Diese Struktur ermöglicht eine effiziente Zuweisung von NTFS-Berechtigungen auf den zentralen DFS-Dateifreigaben..
Die Absicherung der Domäne erfolgt über gezielte Baselines wie die Server_BaselineSecurity, welche NTLMv2-Authentifizierung erzwingt und Kerberos auf AES256-Verschlüsselung beschränkt. Durch den Einsatz von LAPS werden lokale Administrator-Passwörter automatisch rotiert, während die GPO UserToolRestriction den Zugriff auf administrative Werkzeuge wie die PowerShell oder regedit.exe für Standardbenutzer unterbindet. Zusätzlich steuern Richtlinien die automatisierte Bereitstellung des zentralen DFS-Shares (S:) sowie der persönlichen Homefolder (U:) und stellen durch Login-Banner sowie BitLocker-Recovery-Vorgaben die Compliance am Endgerät sicher.
Ubuntu-Server lin01 (Ansible Control Node) und lin02 (SFTP-Fileserver) sind über Samba Winbind in die Domain eingebunden. RID-basiertes ID-Mapping übersetzt Windows-SIDs in Linux-UIDs. Die AD-Gruppe LinuxAdmins erhält sudo-Rechte via visudo. SFTP-Berechtigungen werden per ACLs nach Abteilung gesteuert.
FortiSIEM sammelt, korreliert und visualisiert sicherheitsrelevante Ereignisse aus allen Schichten des Netzwerks. Die Architektur besteht aus einem Supervisor im DataCenter, einem Worker und zwei standortspezifischen Collectors. Als Backend dient eine ClickHouse-Datenbank, die auch bei hohem Log-Volumen stabile Abfragezeiten ermöglicht. Die Einbindung der Systeme erfolgt je nach Plattform über unterschiedliche Protokolle.
Domain Controller und PAW-Stationen werden über den FortiAgent (Windows-Agent v7.3) überwacht. Der Agent liefert Windows Security Events direkt an den Supervisor. Auf DC1 und DC2 wurden Templates für Security Events konfiguriert und per SIEM-User registriert. Version 7.4 des Agents war mit Windows Server 2022 Datacenter inkompatibel (Fehlercode 0x80070643); ein Downgrade auf v7.3 behob das Problem.
Office-Clients werden über WMI via WinRM (Port 5985) überwacht, da die klassische DCOM-Transportschicht des Collectors NTLMv1 nutzt – inkompatibel mit der seit März 2023 erzwungenen DCOM-Härtung. Ein dedizierter Service-Account nach Least-Privilege-Prinzip mit Remote Enable und Execute-Methods-Rechten auf Root\CIMV2 wird per GPO auf alle Clients ausgerollt.
Linux-Server und FortiGates senden Performance-Daten via SNMPv3 (authPriv, User snmpUser) und Security-Events via syslog-ng bzw. FortiGate-Syslog-Einstellungen. Da die Standard-SNMP-View systemonly nur minimale OIDs freigibt, wurde eine eigene View „all" erstellt und dem SNMPv3-User zugewiesen.
Konfigurierte Dashboards: Domain Controller Monitoring, Windows Clients Security (Event-IDs 4624/4634/4672), Linux Server Health, FortiGate TrafficFlow mit Google Maps API. Korrelationsregeln für Brute-Force, Lateral Movement, Kerberoasting und OT-Impact generieren automatisch priorisierte Incidents.
Für die Absicherung beider Standorte kommen FortiGate VM64-Instanzen (v7.4.9) zum Einsatz. Der Datenverkehr ist standardmäßig auf implicit deny gesetzt – sämtlicher Traffic muss explizit freigegeben werden. Um einen Firewall-Ausfall zu vermeiden, sind die Instanzen als Active-Passive HA-Cluster konfiguriert. Die Standortverbindung erfolgt über ein IPsec Site-to-Site VPN mit automatischem Auto-negotiate.
Die initiale Konfiguration erfolgt über die CLI, bevor die GUI zugänglich ist. Port3 bedient die internen VLANs am jeweiligen Standort; Port4 und Port5 stellen die ISP-Anbindungen her. Port6 ist als Heartbeat-Interface für den HA-Cluster reserviert. Jede Instanz benötigt eine registrierte Fortinet-Lizenz, die beim Start online abgefragt wird.
Die VLANs sind als eigene logische Interfaces auf der Firewall konfiguriert, sodass Routing und Sicherheitsrichtlinien zentral durchgesetzt werden. Für die Kommunikation zwischen internen VLANs ist NAT deaktiviert, da keine Adressübersetzung erforderlich ist. Policies regeln explizit, welcher VLAN-Traffic zugelassen wird.
Zwei FortiGates derselben Version und Lizenzstufe bilden den Cluster. Die Heartbeat-Interfaces beider Instanzen befinden sich in derselben vSphere-Portgruppe, für die Promiscuous Mode, MAC Address Changes und Forged Transmits aktiviert sein müssen. Im Fehlerfall übernimmt die passive Instanz automatisch den Betrieb.
Zwischen DataCenter und Office ist ein IPsec-Tunnel über die FortiGates aufgebaut, konfiguriert per IPsec Wizard in der GUI. Als Authentifizierungsmethode wurde Pre-Shared Key gewählt. Phase-1- und Phase-2-Parameter werden spiegelbildlich auf beiden Firewalls konfiguriert; nur der Datenverkehr zwischen den definierten lokalen und entfernten Subnetzen wird durch den Tunnel geleitet.
In sicherheitskritischen Netzwerken ist ein direkter Zugriff auf interne Systeme aus dem Nutzernetz heraus nicht wünschenswert. Der Jump Host dient als zentraler, gehärteter Zwischenknoten: Administratoren oder OT-Engineers verbinden sich zunächst per RDP mit dem Jump Host und greifen von dort auf die Zielsysteme – insbesondere das HMI der Aufzugs-SPS – zu. Der Jump Host ist Mitglied der Domain ascend.da.at, sodass zentrale Sicherheitsrichtlinien automatisch greifen.
Eine eigene GPO Jumphost_OT_Access steuert, wer den Jump Host per RDP nutzen darf. Über die Richtlinie „Anmelden über Remotedesktopdienste zulassen" sind ausschließlich Domain Admins, Network Administrators und OT Engineers berechtigt. Die lokale Gruppe Remotedesktopbenutzer wird per „Eingeschränkte Gruppen" auf genau diese Domänengruppen beschränkt.
Für OT Engineers wurde eine benutzerdefinierte Benutzeroberfläche per GPO konfiguriert: Microsoft Edge startet im Kiosk-Modus direkt auf der HMI-Adresse der SPS. Dadurch können ausschließlich die Aufzugssteuerung bedient und keine anderen Anwendungen oder Webseiten aufgerufen werden. Für Administratoren ist zusätzlich eine Softwareeinschränkungsrichtlinie aktiv, die nicht explizit freigegebene Programme blockiert. Getrennte RDP-Sitzungen werden nach einem konfigurierten Zeitlimit automatisch beendet.
OT Engineers verbinden sich per RDP mit dem Jump Host. Dort startet Edge automatisch im Kiosk-Modus auf der HMI-IP der S7-1200 – der Zugriff beschränkt sich auf die Aufzugssteuerung. Direkte Verbindungen aus dem Büro- oder IT-Netz ins OT-Segment sind durch Firewall-Policies unterbunden. Der Zugriffspfad ist damit vollständig nachvollziehbar und im SIEM protokolliert.
Im Angriffsszenario von ASCEND stellt der Jump Host eine notwendige Zwischenstufe dar: erst nach erfolgreichem Kerberoasting und Übernahme eines OT-Engineer-Kontos ist der Weg zum HMI offen. Der Jump Host macht diesen Schritt sichtbar – und ist damit gleichzeitig Schutzmaßnahme und forensischer Ankerpunkt.
Der Modellaufzug wurde vollständig selbst konstruiert und programmiert. Das dreigeschossige Gehäuse besteht aus Buchenleisten, Sperrholzplatten und Aluminiumprofilen. Schrittmotoren, Reed-Sensoren, Motorcontroller und eine Siemens S7-1200 SPS sind auf einer Hutschiene montiert. Die Steuerlogik ist in SCL (Structured Control Language) implementiert; ein webbasiertes HMI direkt auf der CPU ermöglicht die Bedienung über jeden Browser.
Siemens SIMATIC S7-1200 CPU 1214C DC/DC/DC: 14 digitale Eingänge, 10 digitale Ausgänge, 4 Pulsausgänge für Schrittmotoren. Im Modell sind vier Schrittmotoren verbaut – je einer für Schacht und Türantrieb pro Etage; jeder benötigt einen PUL- und einen DIR-Ausgang an der SPS. Reed-Sensoren dienen als Homing-Referenz und Endschalter. Das Modellgebäude wurde aus Holz und Aluminiumprofilen selbst gefertigt; die Führung der Kabine läuft über Aluminiumprofile mit Riemenantrieb.
Die Steuerlogik ist als Zustandsautomat konzipiert und in SCL (Structured Control Language) implementiert – eine Pascal-basierte Hochsprache, die im TIA Portal V20 verwendet wird. Motion-Control-Technologieobjekte steuern die Schrittmotoren über MoveAbsolute-Befehle nach einer Homing-Referenzfahrt. Separate Bausteine übernehmen Außenruf-, Innenruf- und Bewegungslogik. Fehlerhafte TO-Parameter führten initial zu Homing-Fehlern, die durch Parameterkorrektur im TIA Portal behoben wurden.
Der integrierte Webserver der S7-1200 hostet HTML/CSS/JS direkt auf der CPU. Die Funktion „Anwenderseiten" ermöglicht eigene Webseiten ohne externe Server. AWP-Kommentare verknüpfen HTML-Variablen mit SPS-Datenbausteinen. Über den Browser können der aktuelle Aufzugsstatus angezeigt und Zielstockwerke gesetzt werden. Kein separates HMI-Gerät ist erforderlich; der Zugriff erfolgt über HTTP aus dem Netzwerk.
Der Kabinen-Innenruf ist nicht klassisch verdrahtet, sondern über Modbus TCP realisiert: Ein Raspberry Pi agiert als Modbus-TCP-Client, die S7-1200 SPS als Server. Damit wird die herkömmliche, aufwändige Einzelverdrahtung durch eine netzwerkbasierte Lösung ersetzt. Da es sich beim Aufzug um ein Modell handelt, ist der Innenruf beispielhaft außerhalb der Kabine angebracht.
ASCEND demonstriert anhand einer vollständigen Angriffskette, wie ein externer Angreifer schrittweise bis zur physischen Aufzugssteuerung vordringen kann. Jeder Schritt wird vom FortiSIEM über Korrelationsregeln erkannt und als priorisierter Incident im Dashboard sichtbar gemacht.
Shodan-Suche nach öffentlichen FortiGate-Instanzen; Nmap-Portscan des Firewall-Subnetzes zur Angriffsvorbereitung
Hydra-Angriff auf das FortiGate-Webinterface – SIEM erkennt via Korrelationsregel die Login-Fehler und generiert einen Incident
SSH-Zugriff auf PAW-Stationen mit dem kompromittierten Konto – Korrelation im SIEM verknüpft die Kali-Quell-IP mit Event 4624 der PAW
Kerberos-Ticket für srv_hmi_access (SPN: http/hmi-elevator.local) angefordert und via Impacket + John the Ripper offline gecrackt
Zugriff auf das HMI der Siemens S7-1200 über den Jump Host – unautorisierte Manipulation der Aufzugssteuerung wird im SIEM als Incident geloggt
Von der ersten SPS-Recherche im Juni 2025 bis zur abgeschlossenen Angriffskette im Februar 2026 – ein Überblick über die wichtigsten Meilensteine, Wendepunkte und die intensivsten Phasen des Projekts.
Projektorganisation via MS Planner, Teams und Trello. Erste SPS-Versuche mit der Siemens LOGO, TIA Portal Installation, erste GNS3-Netzwerkprototypen für WAN und ISPs, Logo-Entwürfe in Adobe Illustrator.
Projektantrag erstellt, nach erster Zurückweisung überarbeitet und erfolgreich eingereicht. PSP, OSP, Risikoanalyse und Stakeholderanalyse erarbeitet. Sponsoring-Anfragen an OBI, Schindler, Otis, CANCOM und Reichelt Elektronik.
OBI-Einkauf, Otis-Besuch (Taster & Panels erhalten), Schindler-Meeting. Bau des Liftschachts aus Holzleisten und Aluminium. UCS/vSphere-Setup, FortiGate HA-Cluster, Active Directory mit Ansible. Interne TOFT-Präsentation.
Homing und MoveAbsolute nach intensivem Troubleshooting funktional. DFS-Replikation zwischen DC1 und DC2 eingerichtet. SIEM-Anbindung der ersten Systeme (FortiAgent auf DCs). Interne Vorpräsentation abgehalten.
Nach den Weihnachtsferien starteten auf DC1 kritische Services nicht mehr – Netlogon, DFS, LanmanWorkstation. Tagelange Fehleranalyse, SYSVOL-Replikation vollständig unterbrochen. Ein Authoritative Restore stellte das Active Directory wieder her.
Alle 5 Angriffsstufen umgesetzt und im SIEM erkannt. Modellhaus-Verkleidungen, Kabelkanäle und Innenbeleuchtung montiert. ZeroTier-VPN für Remote-OT-Zugriff konfiguriert. INNKOO-Hearing auf MS Teams. DA-Buch weitgehend fertiggestellt.
DA-Buch-Finalisierung, letzte Optimierungen am Modellaufzug und den SIEM-Dashboards. Statusmeetings mit dem Betreuerteam. Vorbereitung der Abschlusspräsentation.
Im Verlauf des Projekts traten mehrere technische Herausforderungen auf, die oft intensive Fehleranalyse über alle Ebenen der Infrastruktur hinweg erforderten. Die folgenden Fallbeispiele dokumentieren zentrale Herausforderungen aus den Bereichen Netzwerktechnik, Systemadministration, Security und OT im Projekt sowie die zugehörigen Lösungswege.
Der Login-Bereich der vSphere-Oberfläche war ausgegraut. Analyse ergab: Der SSO-Handshake scheiterte, weil der Heimrouter nur MTU 1452 zuließ – das VPN-gekapselte Paket überschritt die zulässige Größe.
Manuelle MTU-Anpassung am WAN-Interface auf 1452 – Login sofort erfolgreich.
Nach den Weihnachtsferien starteten auf DC1 Netlogon, DFS und LanmanWorkstation nicht mehr. dcdiag zeigte DFSR-Fehler, der Secure Channel war unterbrochen. Mehrere Reparaturversuche blieben ohne Wirkung.
Authoritative Restore von SYSVOL auf DC1 – Event 4604 bestätigte den Erfolg.
Installation des FortiAgents 7.4 auf den Domain Controllern schlug fehl – ein bekannter Inkompatibilitätsfehler zwischen Agent-Version 7.4 und Windows Server 2022 Datacenter.
Downgrade auf FortiAgent 7.3 – Installation erfolgreich, Events fließen korrekt zum Supervisor.
Der SIEM-Collector konnte Office-Clients nicht via WMI/DCOM abfragen. Die interne Java-Bibliothek (J-Interop) des Collectors ist auf NTLMv1 festgeschrieben – inkompatibel mit der seit März 2023 erzwungenen DCOM-Härtung von Microsoft.
Umstellung auf WMI via WinRM mit einem Least-Privilege Service-Account – alle Geräte eingebunden.
SNMP-Polling lieferte nur minimale Metriken, da die Standard-View systemonly den OID-Baum stark einschränkt. Im SIEM fehlten wichtige Performance-Daten der Linux-Server.
Eigene SNMP-View „all" erstellt und dem SNMPv3-User zugewiesen – vollständige Metriken im SIEM.
Auf dem UCS-Cluster waren nur vmnic4 und vmnic5 als funktionierende Uplinks nutzbar. Mehrere dvSwitches kollidierten; Pings zwischen den Standorten waren intermittierend nicht möglich.
Konsolidierung auf einen dvSwitch mit klarer VLAN-Trunk-Konfiguration – stabile Konnektivität.
Nach initialer Homing-Implementierung warf der untere Endschalter eine Fehlermeldung; MoveAbsolute funktionierte nicht. Ursache waren fehlerhafte Parameter der Technologieobjekte im TIA Portal.
Korrektur der TO-Parameter und Anpassung der Referenzposition – Homing und MoveAbsolute stabil.
Offline-Cracking des Kerberos-Tickets für srv_hmi_access mit John the Ripper schlug zunächst fehl, da die AES256-Härtung des Service Accounts das klassische RC4-Kerberoasting verhinderte. Der extrahierte Hash war mit dem Standard-Ansatz nicht crackbar.
Erzwungener RC4-Ticket-Request via Impacket – Hash extrahiert und erfolgreich geknackt.
Von Juni 2025 bis März 2026 investierten die fünf Teammitglieder insgesamt mehr als 1.200 Stunden in ASCEND – verteilt auf Konzeption, Implementierung, Hardwarebau, Dokumentation und Präsentationen. Die arbeitsintensivsten Monate waren September, Oktober und Januar, als Netzwerk, Active Directory und Modellaufzug gleichzeitig aufgebaut wurden.