Verdächtige Aktivitäten auf einem Firmen-PC untersuchen

Ein wiederholbarer Workflow für KMUs und MSPs: Live-View für den Ist-Zustand, Screenshot-History (optional) für die Timeline — damit du Entscheidungen auf Basis von Fakten triffst, nicht auf Basis von Vermutungen.

Live-Grid als Radar nutzen, dann gezielt in einen PC „reinzoomen“.

Manchmal passt etwas einfach nicht zusammen: Ergebnisse passen nicht zu den behaupteten Arbeitszeiten, Kunden beschweren sich über langsame Reaktionen („ich war doch die ganze Zeit dran“), oder du siehst ungewöhnliches Verhalten auf genau einem bestimmten PC. In solchen Situationen willst du nicht raten. Du willst zwei Dinge technisch beantworten können:

(1) Was passiert gerade jetzt? (Live-Ansicht)
(2) Was ist früher passiert? (Screenshot-History, falls aktiviert)

Dieser Artikel macht daraus ein klares Playbook: kurze Live-Triage, danach (wenn nötig) eine zeitbasierte Rekonstruktion, dann eine Entscheidung auf Basis der sichtbaren Fakten. Zielgruppe sind KMU-Owner/Manager und IT-Dienstleister/MSPs, die firmenkontrollierte Windows-PCs betreuen.

Compliance- & Rechtlicher Hinweis (keine Rechtsberatung): Monitoring-Software darf nur genutzt werden, wenn es in deinem Land und für deinen konkreten Use Case zulässig ist (z.B. Schulung, Qualitätssicherung, Security). In vielen Ländern müssen Nutzer informiert werden und/oder einwilligen. Dieser Beitrag ist nur technische Information. Bitte hole vor Einsatz oder Investigation unabhängige Rechtsberatung in allen relevanten Ländern ein und setze Policies, Transparenzmaßnahmen und Zugriffskontrollen um.

1) Was ist „verdächtig“? (Signale + Scope)

In der Praxis startet „verdächtige Aktivität“ fast immer als Signal — nicht als Beweis. Ziel ist schnelle Kontext-Klärung, ohne Überreaktion.

1.1 Typische Signale im KMU-Alltag

• Output-Mismatch: Stunden passen nicht zu sichtbarem Fortschritt.
• Kunden-Feedback: Qualität/Tempo stimmt nicht, obwohl „alles gemacht“ wurde.
• Ungewöhnliches PC-Verhalten: Popups, neue Tools, Installationsfenster, Error-Loops.
• Security-Trigger: AV/EDR-Alarm, Phishing-Verdacht, interner Hinweis.

1.2 Scope definieren (bevor du schaust)

Investigations kippen oft, weil der Scope nicht sauber ist. Definiere vorher:

1. Welche PCs: starte mit einem konkreten Firmen-PC (narrow scope).
2. Welches Zeitfenster: „letzte 30 Minuten“ oder „gestern 14–16 Uhr“.
3. Welcher Zweck: Training/QA/Security-Workflow (intern dokumentieren).
4. Wer darf schauen: Zugriff strikt auf autorisierte Rollen begrenzen.

2) Live-Triage: Was prüfst du in 2–5 Minuten?

Live-View beantwortet „was passiert gerade?“. Technisch ist Live bei Wolfeye typischerweise als periodisches Screenshot-Update umgesetzt (oft ca. alle 2–3 Sekunden, je nach Setup). Ziel ist schnelle Klarheit — nicht endloses Beobachten.

2.1 Erst Grid (Radar), dann Zoom

1. Dashboard öffnen: Grid kurz scannen (Freeze, wiederkehrende Dialoge, ungewöhnliche Fenster).
2. Ziel-PC wählen: in eine größere Einzelansicht öffnen.
3. Kontext prüfen: welche Website/App/Window ist gerade aktiv?

2.2 Was du on-screen prüfen solltest (Checkliste)

• Websites: private Webmail/Cloud, File-Sharing, Shopping/Streaming/Social (Kontext zählt).
• Programme: unautorisierte Remote-Tools, Installer, „portable“ Apps, ungewöhnliche Admin-Tools.
• Dialoge: Credential-Prompts, Security-Warnungen, Fehlerketten.
• Data-Movement: Massenexporte, Bulk-Copy/Rename, ZIP/Archive, Upload-Seiten.

2.3 Schnelle Triage-Fragen (kurz notieren)

• Ist das für diese Rolle plausible Arbeit?
• Wirkt die Person festgefahren (Training/Support) oder aktiv riskant?
• Braucht es sofortige Eskalation oder reicht ein geordneter Follow-up?

Grid-Ansicht für schnelle Übersicht; Einzelansicht für Details.

3) Screenshot-History: Timeline rekonstruieren (falls aktiviert)

Live allein beantwortet nicht „was war vorher?“. Dafür ist Screenshot-History da — aber nur, wenn du sie aktiviert hast und nur dort, wo du wirklich eine Timeline brauchst.

3.1 Technisches Grundprinzip: Live ist nicht automatisch „gespeichert“

In einem screenshot-basierten Live-Setup wird ein aktueller Screenshot an den Server übertragen, damit er im Dashboard angezeigt werden kann. Der vorherige Screenshot wird durch den neuen überschrieben. Das heißt: ohne aktivierte History gibt es keine Timeline — du siehst nur „jetzt“.

3.2 History bewusst aktivieren (Intervall wählen)

History ist häufig standardmäßig deaktiviert. Wenn du sie aktivierst, wählst du typischerweise ein Intervall (z.B. 1/5/10 Minuten). Praxis-Empfehlung:

• 1 Minute: hohe Detailtiefe für kurze Incidents; mehr Material.
• 5 Minuten: oft ein guter Default für KMU-Investigations.
• 10 Minuten: leichter, eher für Pattern-Checks (weniger Detail).

3.3 Timeline bauen (Step-by-step)

1. Zeitfenster definieren: Start/Ende festlegen.
2. Nach Zeitstempel scrollen: App/Website/Window pro Schritt notieren.
3. Transitions markieren: „Export gestartet“, „Upload geöffnet“, „Installer ausgeführt“.
4. Abgleich: Tickets, Kundenbeschwerden, EDR/AV-Events, Chat-Logs (wo intern erlaubt).

4) Incident-Timeline Vorlage (Copy/Paste)

Mit einer einheitlichen Vorlage werden Investigations schneller und sauberer. Kopiere die folgende Struktur in euer Ticket- oder Incident-System. Bleib faktisch und zeitbasiert.

INCIDENT ID:
Gemeldet von:
Datum / Uhrzeit (Zeitzone):
Device (PC-Name):
User / Rolle:
Trigger (warum auffällig?):

SCOPE
- Zeitfenster:
- Live-Check durchgeführt um:
- Screenshot-History aktiv? (ja/nein)
- Intervall (falls ja):

LIVE (JETZT)
- Was ist on-screen?
- Welche Website/App/Window?
- Warnungen/Fehler sichtbar?
- Akute Risikosignale? (ja/nein)

TIMELINE (VERGANGENHEIT)
[Zeit]  [Was ist sichtbar]  [Notizen]
14:05   CRM Export-Seite     Export gestartet
14:10   Archiv-Tool          Großer Ordner komprimiert
14:15   Upload/Webmail       Ziel sichtbar
14:20   Zurück zu Standard   Kontext unklar

ENTSCHEIDUNG
- Harmlos / erwartete Arbeit?
- Training/Coaching nötig?
- Security-Eskalation nötig?
Maßnahmen:
Nächster Review:
Owner:

4.1 Wie „gute Notizen“ aussehen

• Zeitbasiert: „14:15 Upload-Seite geöffnet“ statt „wirkte verdächtig“.
• Spezifisch: App/Website/Window so benennen, wie sichtbar.
• Trigger-gebunden: Notizen mit dem ursprünglichen Signal verknüpfen.

Einzelansicht für Details während Investigation — nicht als Dauer-View.

5) Entscheidungspfade: harmlos vs. Training vs. Security-Eskalation

Nach Triage und ggf. Timeline landet ihr meist in einem von drei Bereichen. Das hält das Thema sachlich und vermeidet „Monitoring-Drama“.

5.1 Bucket A: harmlos / erwartete Arbeit

• Faktisch dokumentieren („Kontext bestätigt“).
• Rückmeldung an Requester (Owner/Kunde/Manager).
• Bei Bedarf Rollen-/Prozessklärung (wenn ungewöhnlich, aber legitim).

5.2 Bucket B: Prozess-Reibung oder Training-Gap (sehr häufig)

• Bottleneck finden: fehlende Zugänge, unklare SOP, Tool-Probleme, Rework.
• Verbessern: SOP anpassen, Coaching, Berechtigungen/Tooling fixen.
• Später kurz re-checken (trigger-basiert, nicht permanent).

5.3 Bucket C: Security-Eskalation (Incident behandeln)

Wenn starke Indicators sichtbar sind (Installer, Massenexporte zu unapproved Zielen, Credential-Harvesting-Muster etc.), folgt eurem internen Incident-Prozess. Typische technische Schritte (Beispiele):

• Stakeholder: IT/Security Lead, MSP Engineer, Management.
• Containment: Device isolieren, wenn eure Policy das vorsieht.
• Credentials: Passwörter rotieren / Accounts deaktivieren nach Prozess.
• Evidence: formale Security-Tools & Doku verwenden.

Hinweis: Arbeitsrecht/HR und rechtliche Verwertbarkeit sind länderspezifisch. Bitte Rechtsberatung einholen, bevor Maßnahmen ergriffen werden, die Employment/Privacy betreffen.

6) MSP-Workflow: Investigations sauber für Kunden durchführen

Für IT-Dienstleister ist schnelle Incident-Klärung wertvoll — aber Governance ist Pflicht. Ein sauberer Workflow reduziert Fehler und stärkt Vertrauen.

6.1 MSP-Checkliste (operativ)

• Vertraglicher Scope: Monitoring/Investigation muss vereinbart sein.
• Kundenrollen: wer darf Review anfordern, wer darf Ergebnisse sehen?
• Trennung: Kundentrennung über Dashboards/Naming/Zugriff.
• Trigger statt Always-on: Reviews nur bei Anlass (QA/Incident/Training).

6.2 Als Outcome verkaufen (nicht als Überwachung)

Kunden kaufen Outcomes: schneller Support, schnellere Incident-Klärung, besseres Training/QA. Mit klaren Grenzen (Scope, Zugriff, Zweck) kann das als Managed Service funktionieren.

7) Video: Verdächtige Aktivität untersuchen (Live View + History)

Das Video zeigt den Ablauf: Live-Dashboard öffnen, in einen PC in der großen Ansicht zoomen und (falls aktiviert) die Screenshot-History nach Datum/Uhrzeit durchgehen.

Reminder (keine Rechtsberatung): Monitoring nur nutzen, wenn es im Land und Use Case zulässig ist. Wo erforderlich: informieren und Einwilligung einholen. Bitte vor produktivem Einsatz unabhängige Rechtsberatung einholen.

Video: „How to Investigate Suspicious Activity on a Company PC - Live View + History“.

Fazit

Wenn etwas „komisch“ wirkt, ist das beste Ergebnis nicht „mehr Monitoring“, sondern schnellere Klarheit. Eine kurze Live-Triage zeigt, was gerade passiert. Eine Screenshot-Timeline (falls aktiviert) hilft, den Ablauf nach Zeitstempeln zu rekonstruieren und Entscheidungen auf Fakten zu stützen.

Das Modell ist simpel: Triage → Timeline → Entscheidung. Scope klein halten, Fakten notieren, Zugriff begrenzen und in eure normalen Support/QA/Security-Prozesse integrieren.

Finaler Reminder (keine Rechtsberatung): Monitoring ist nur zulässig, wenn es im Land und Use Case erlaubt ist. Wo erforderlich: informieren und Einwilligung einholen. Bitte vor produktiver Nutzung unabhängige Rechtsberatung einholen.

Wolfeye ist Monitoring-Software. Jeder Einsatz muss mit den Gesetzen und Vorschriften in allen relevanten Ländern, deiner Branche und deinem konkreten Use Case übereinstimmen (z.B. Schulung, Qualitätssicherung oder Sicherheit). In vielen Jurisdiktionen hängt die Zulässigkeit u.a. von vorheriger Information der Nutzer und Einwilligung ab. Dieser Beitrag und das eingebettete Video dienen nur der allgemeinen technischen und organisatorischen Information und stellen keine Rechtsberatung und keine Zusage zur rechtlichen Zulässigkeit dar.