Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
drs-malware-scan — Führen Sie einen dateibasierten Malware-Scan auf Ihren lokalen Servern mit AWS durch. | Kitploit
Tools/GitHubGitHub/aws-samples/drs-malware-scan
SchwachstellenscannerMalware-AnalyseCloud-SicherheitBedrohungsanalyseIncident Response
GitHubaws-samples/drs-malware-scan

drs-malware-scan

Führen Sie einen dateibasierten Malware-Scan auf Ihren lokalen Servern mit AWS durch.

Repository anzeigen
14225vor 2 JahrenNoch nicht geprüft
Webseite

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

Durchführung einer Malware-Scan-Analyse von lokalen Servern mit AWS-Services

Herausforderungen bei der Malware-Erkennung vor Ort (on-premises)

Für Sicherheitsteams kann es aufgrund von Budget- und Ressourcenbeschränkungen schwierig sein, alle lokalen Server kontinuierlich zu überwachen. Ein signaturbasiertes Antivirenprogramm allein ist nicht ausreichend, da moderne Malware verschiedene Verschleierungstechniken einsetzt. Serveradministratoren haben möglicherweise historisch gesehen keine Transparenz über Sicherheitsereignisse auf allen Servern. Ohne zentralisierte Überwachung und Alarmierung ist es schwierig, kompromittierte Systeme und sichere Backups für die Wiederherstellung bei Vorfällen zu identifizieren. Für Serveradministratoren ist es aufwändig, zusätzliche Sicherheitstools für die erweiterte Bedrohungserkennung einzurichten und zu warten. Die schnelle mittlere Erkennungs- und Behebungszeit von Infektionen ist entscheidend, aber ohne die richtige automatisierte Lösung schwer zu erreichen.

Zu bestimmen, welches Backup-Image während eines Vorfalls ohne umfassende Bedrohungsinformationen sicher wiederhergestellt werden kann, ist ein weiteres schwieriges Problem. Selbst wenn Backups verfügbar sind, ist es riskant, blind aus Backups wiederherzustellen, ohne zu wissen, wann genau ein System kompromittiert wurde. Dies erhöht die Wahrscheinlichkeit, Malware wiederherzustellen und während der Incident-Response noch mehr wertvolle Daten und Systeme zu verlieren. Es besteht Bedarf an einer automatisierten Lösung, die den Zeitpunkt des Eindringens genau bestimmen und sichere Backups für die Wiederherstellung empfehlen kann.

Verwendung von AWS-Services zur Bewältigung dieser Herausforderungen

Die Lösung nutzt AWS Elastic Disaster Recovery (AWS DRS), Amazon GuardDuty und AWS Security Hub, um die Herausforderungen der Malware-Erkennung für lokale Server zu bewältigen.

Diese Kombination von Diensten bietet eine kosteneffiziente Möglichkeit, lokale Server kontinuierlich auf Malware zu überwachen, ohne die Leistung zu beeinträchtigen. Sie hilft auch dabei, sichere Wiederherstellungspunkte in der Zeit für Backups zu bestimmen, indem sie den Zeitplan der Kompromittierung durch zentralisierte Bedrohungsanalysen identifiziert.

  • AWS Elastic Disaster Recovery (AWS DRS) minimiert Ausfallzeiten und Datenverluste mit schneller, zuverlässiger Wiederherstellung von lokalen und cloudbasierten Anwendungen durch kostengünstigen Speicher, minimale Rechenleistung und Point-in-Time-Wiederherstellung.
  • Amazon GuardDuty ist ein Bedrohungserkennungsdienst, der Ihre AWS-Konten und Workloads kontinuierlich auf böswillige Aktivitäten überwacht und detaillierte Sicherheitsergebnisse für Transparenz und Behebung liefert.
  • AWS Security Hub ist ein Cloud-Sicherheits-Posture-Management-Dienst (CSPM), der Sicherheitsbest-Practice-Prüfungen durchführt, Warnungen aggregiert und automatisierte Behebungen ermöglicht.

Architektur

sample

Lösungsbeschreibung

Die Malware-Scan-Lösung geht davon aus, dass lokale Server bereits mit AWS DRS repliziert werden und Amazon GuardDuty und AWS Security Hub aktiviert sind. Der CDK-Stack in diesem Repository wird nur die im Architekturdiagramm als 'DRS Malware Scan' gekennzeichneten Boxen bereitstellen.

  1. AWS DRS repliziert Quellserver aus der lokalen Umgebung zu AWS (oder von jedem anderen Cloud-Anbieter). Weitere Informationen zur Einrichtung von AWS DRS finden Sie im Quick Start Guide.
  2. Amazon GuardDuty ist bereits aktiviert.
  3. AWS Security Hub ist bereits aktiviert.
  4. Die Malware-Scan-Lösung wird durch eine Zeitplanregel in Amazon EventBridge ausgelöst (mit Präfix DrsMalwareScanStack-ScheduleScanRule). Sie können die Scanfrequenz nach Bedarf anpassen (z.B. einmal täglich, wöchentlich usw.).
  5. Die Zeitplanregel in Amazon EventBridge löst die Lambda-Funktion Submit Orders aus (mit Präfix DrsMalwareScanStack-SubmitOrders), die die zu scannenden Quellserver aus der DynamoDB-Tabelle Source Servers sammelt.
  6. Aufträge werden in die SQS-FIFO-Warteschlange Scan Orders gestellt (mit Präfix DrsMalwareScanStack-ScanOrdersfifo). Die Warteschlange wird verwendet, um der gleichen DRS-Instanz zugeordnete Scan-Anfragen zu serialisieren und eine Race-Condition zu verhindern.
  7. Die Lambda-Funktion Process Order nimmt einen Malware-Scan-Auftrag aus der Warteschlange und reichert ihn an, um den bevorstehenden Malware-Scan-Vorgang vorzubereiten. Beispielsweise fügt sie die ID der replizierenden DRS-Instanz ein, die dem im Auftrag angegebenen DRS-Quellserver zugeordnet ist. Die Ausgabe von Process Order sind Malware-Scan-Befehle, die alle notwendigen Informationen zum Aufrufen des GuardDuty-Malware-Scans enthalten.
  8. Malware-Scan-Vorgänge werden mit der DRSVolumeAnnotationsDDBTable auf Volume-Ebene verfolgt, was Berichtsfunktionen bietet.
  9. Malware-Scan-Befehle werden in die SQS-FIFO-Warteschlange Scan Commands eingefügt (mit Präfix DrsMalwareScanStack-ScanCommandsfifo), um die Ausfallsicherheit zu erhöhen.
  10. Die Funktion Process Commands übermittelt in der Warteschlange befindliche Scan-Befehle mit einer maximalen Rate von 1 Befehl pro Sekunde, um API-Drosselung zu vermeiden. Sie löst die On-Demand-Malware-Scan-Funktion von Amazon GuardDuty aus.
  11. Die Ausführung des On-Demand-Amazon-GuardDuty-Malware-Jobs kann über den Amazon GuardDuty-Dienst überwacht werden.
  12. Das Ergebnis des Malware-Scan-Jobs wird an Amazon Cloudwath Logs weitergeleitet.
  13. Die Lambda-Funktion Subscription Filter empfängt das Ergebnis des Scans und verfolgt das Ergebnis mit DynamoDB (Schritt #14).
  14. Die DynamoDB-Tabelle DRS Instance Annotations verfolgt den Status des Malware-Scan-Jobs auf Instanzebene.
  15. Der CDK-Stack mit dem Namen ScanReportStack stellt die Lambda-Funktion Scan Report bereit (mit Präfix ScanReportStack-ScanReport), um den Amazon S3 Bucket mit Präfix scanreportstack-scanreportbucket zu befüllen.
  16. AWS Security Hub aggregiert und korreliert Erkenntnisse von Amazon GuardDuty.
  17. Das Security-Hub-Finding-Ereignis wird von einer EventBridge-Regel abgefangen (mit Präfix DrsMalwareScanStack-SecurityHubAnnotationsRule)
  18. Die Lambda-Funktion Security Hub Annotations (mit Präfix DrsMalwareScanStack-SecurityHubAnnotation) generiert zusätzliche Notizen (Annotationen) zum Finding mit kontextualisierten Informationen über den betroffenen Quellserver. Diese zusätzlichen Informationen sind im Abschnitt Notizen des Security-Hub-Findings zu sehen.
  19. Die Folgeaktivitäten hängen vom verwendeten Incident-Response-Prozess ab. Basierend auf dem Datum der Infektion kann AWS DRS beispielsweise verwendet werden, um eine Point-in-Time-Wiederherstellung mit einem Snapshot vor dem Datum der Malware-Infektion durchzuführen.
  20. In einem Multi-Account-Szenario kann diese Lösung direkt auf dem AWS-Konto bereitgestellt werden, das die AWS-DRS-Lösung hostet. Die Amazon-GuardDuty-Erkenntnisse werden automatisch an das zentralisierte Sicherheitskonto gesendet.

Verwendung

Voraussetzungen

  • Ein AWS-Konto.

  • Amazon Elastic Disaster Recovery (DRS) konfiguriert, mit mindestens einem synchronisierten Quellserver. Falls nicht, lesen Sie bitte diese Dokumentation. Die Replikationskonfiguration muss EBS-Verschlüsselung mit einem benutzerdefinierten verwalteten Schlüssel (CMK) von AWS Key Management Service (AWS KMS) berücksichtigen. Amazon GuardDuty Malware Protection unterstützt den standardmäßigen von AWS verwalteten Schlüssel für EBS nicht.

  • IAM-Berechtigungen zur Bereitstellung der Komponenten dieser Lösung.

  • Amazon GuardDuty aktiviert. Falls nicht, lesen Sie bitte diese Dokumentation

  • Amazon Security Hub aktiviert. Falls nicht, lesen Sie bitte diese Dokumentation

    Warnung
    Derzeit unterstützt der Amazon GuardDuty Malware-Scan keine EBS-Volumes, die mit von EBS verwalteten Schlüsseln verschlüsselt sind. Wenn Sie diese Lösung verwenden möchten, um Ihre lokalen (oder andere Cloud-)Server zu scannen, die mit DRS repliziert werden, müssen Sie die DRS-Replikation mit Ihrem eigenen Verschlüsselungsschlüssel in KMS einrichten. Wenn Sie derzeit von EBS verwaltete Schlüssel für Ihre replizierenden Server verwenden, können Sie die Verschlüsselungseinstellungen in der DRS-Konsole ändern, um Ihren eigenen KMS-Schlüssel zu verwenden.

Bereitstellung

  1. Erstellen Sie eine Cloud9-Umgebung mit einem Ubuntu-Image (mindestens t3.small für bessere Leistung) in Ihrem AWS-Konto. Öffnen Sie Ihre Cloud9-Umgebung und klonen Sie den Code aus diesem Repository. Hinweis: Amazon Linux 2 hat Node v16, das seit dem 11.09.2023 nicht mehr unterstützt wird.

    root@kitploit:~
    git clone https://github.com/aws-samples/drs-malware-scan
    
    root@kitploit:~
    cd drs-malware-scan
    
    root@kitploit:~
    sh check_loggroup.sh
    
  2. Stellen Sie den CDK-Stack bereit, indem Sie den folgenden Befehl im Cloud9-Terminal ausführen und bestätigen Sie die Bereitstellung.

    root@kitploit:~
    npm install
    
    root@kitploit:~
    cdk bootstrap
    
    root@kitploit:~
    cdk deploy --all
    

    Hinweis
    Die Lösung besteht aus 2 Stacks:

    • DrsMalwareScanStack: Stellt alle für die Malware-Scan-Funktion erforderlichen Ressourcen bereit. Dieser Stack ist obligatorisch. Wenn Sie nur diesen Stack bereitstellen möchten, können Sie cdk deploy DrsMalwareScanStack ausführen.
    • ScanReportStack: Stellt die für die Berichterstellung erforderlichen Ressourcen bereit (Amazon Lambda und Amazon S3). Dieser Stack ist optional. Wenn Sie nur diesen Stack bereitstellen möchten, können Sie cdk deploy ScanReportStack ausführen.

    Wenn Sie beide Stacks bereitstellen möchten, können Sie cdk deploy --all ausführen.

Konfiguration

  1. Stellen Sie sicher, dass die DRS-Quellserver kontinuierlich replizieren und sich in einem fehlerfreien Replikationszustand befinden. Dies ist aufgrund einer Einschränkung der GuardDuty-API erforderlich: Zum Zeitpunkt der Erstellung dieses Dokuments gibt es keine öffentliche AWS-API zum Scannen von DRS-Snapshots. Die einzige Möglichkeit, einen Malware-Scan über DRS-Quellserverdaten durchzuführen, besteht darin, einen Scan auf den von AWS DRS verwalteten Replikationsservern (Amazon EC2-Instanzen) durchzuführen. Wenn die Replikation nicht in einem fehlerfreien Zustand läuft, wird Ihr DRS-Malware-Scan möglicherweise nicht erfolgreich abgeschlossen. Sie müssen ReadyforRecovery=Ready bestätigen.

  2. Identifizieren Sie die zu scannenden Quellserver. Aus allen Servern, die mit AWS DRS repliziert werden, müssen Sie die Liste der Kandidatenserver zum Scannen bestimmen. Kopieren Sie aus der AWS DRS-Konsole die Namen der Quellserver, die die Lösung scannen soll, und fügen Sie sie in einen Texteditor ein. Dies wird im nächsten Schritt verwendet.

        sample

  1. Aktualisieren Sie die DynamoDB-Tabelle. Die Liste der zu scannenden Server wird in einer DynamoDB-Tabelle gespeichert, die vom CDK-Stack erstellt wurde (mit Präfix DrsMalwareScanStack-SourceServersDDBTable). Sie müssen DynamoDB-Elemente für jeden Quellserver erstellen, der von AWS DRS repliziert wird. Gehen Sie dazu zum Amazon DynamoDB-Dienst und befolgen Sie diese Schritte:

        sample

  1. Planen Sie den Malware-Scan-Job. Sie können zum Amazon EventBridge-Dienst gehen und die vorhandene, vom Stack erstellte Regel ändern. Bearbeiten Sie die Regel mit Präfix DrsMalwareScanStack-ScheduleScanRule, legen Sie die Scan-Frequenz der Malware-Scan-Analyse fest. Diese Regel ist standardmäßig DEAKTIVIERT, bitte AKTIVIEREN Sie sie.

        sample

  1. Überprüfen Sie, ob Amazon GuardDuty einen Malware-Scan-Vorgang ausgelöst hat. Um zu bestätigen, dass die Lösung wie erwartet funktioniert, können Sie in der Amazon GuardDuty -> Malware scans-Konsole nachsehen. Einige Sekunden nach dem geplanten Zeitpunkt sollten Sie einen Job mit ScanStatus = Running sehen. Falls nicht, lesen Sie bitte den Abschnitt zur Fehlerbehebung unten.

        sample

  1. Überprüfen Sie AWS Security Hub auf mögliche Malware-Funde auf lokalen Servern. Die Integration von Amazon GuardDuty mit Security Hub ermöglicht es Ihnen, Erkenntnisse von GuardDuty an Security Hub zu senden.
    • Security Hub zeigt nur Erkenntnisse an, daher werden Malware-Scan-Jobs mit ScanResult=Clean nicht in der Security Hub-Konsole angezeigt (nur solche mit ScanResult=Infected).
    • In der AWS Security Hub-Konsole können Sie zu Erkenntnisse gehen und einen Filter nach ProductName=GuardDuty anwenden (wie in der untenstehenden Animation gezeigt).
    • Die Lösung fügt dem Abschnitt Notizen der Erkenntnis Anmerkungen hinzu, die den Namen der infizierten lokalen Server hervorheben.
    • Security Hub ist mit Amazon EventBridge integriert, um Reaktions- und Behebungsaktivitäten einfach zu automatisieren, wie das Senden einer E-Mail an ein SOC, das Melden des Vorfalls in einem Slack-Kanal usw. Weitere Details finden Sie unter diesem Link.

        sample

  1. Optional: Überprüfen Sie die Malware-Scan-Berichtsdatei auf S3. Falls Sie den ScanReportStack bereitgestellt haben, können Sie einen Bericht planen, der so oft wie gewünscht ausgeführt wird. Der Bericht extrahiert den Inhalt der DynamoDB-Tabelle DRSVolumeAnnotationsDDBTable und schreibt ihn in den vom Stack erstellten Amazon S3 Bucket (mit Präfix scanreportstack-scanreportbucket). Dieser Bericht wird jedes Mal überschrieben (und ist kumulativ), wenn die Regel ausgelöst wird.

    • Aktivieren Sie die Amazon EventBridge-Regel und legen Sie den Zeitplan für die Ausführung des Berichts fest: Bearbeiten Sie die Regel mit Präfix ScanReportStack-ScanReportRule, um die Scan-Frequenz der Malware-Scan-Analyse und die Liste der zu analysierenden DRS-Quellserver festzulegen. Auch diese Regel ist standardmäßig deaktiviert, bitte aktivieren Sie sie.

           sample

    • Um den Bericht zu überprüfen, können Sie die CSV-Datei im Amazon S3 Bucket abfragen (mit Präfix scanreportstack-scanreportbucket)

           sample

  2. Optional: Für Multiaccount-Konfiguration. Falls Sie ein dediziertes Sicherheitskonto haben, um alle Sicherheitserkenntnisse im Rahmen einer Multiaccount-Strategie zu zentralisieren, funktioniert diese Lösung ebenfalls. Das Sicherheitsteam kann dieselbe Analyse über das Sicherheitskonto durchführen; die in den verknüpften Konten gemeldeten Security Hub- und GuardDuty-Erkenntnisse werden automatisch in das zentralisierte Sicherheitskonto kopiert.

Fehlerbehebung

Alle Lambda-Funktionen leiten Logs an Amazon CloudWatch weiter. Sie können die Ausführung jeder Funktion überprüfen, indem Sie die entsprechenden CloudWatch-Loggruppen für jede Funktion inspizieren. Suchen Sie nach dem Muster /aws/lambda/DrsMalwareScanStack-*.

Die Dauer des Malware-Scan-Vorgangs hängt von der Anzahl der zu scannenden Server/Volumes (und deren Größe) ab. Wenn Amazon GuardDuty Malware findet, generiert es ein SecurityHub-Finding: Die Lösung fängt dieses Ereignis ab und führt die Lambda-Funktion $StackName-SecurityHubAnnotations aus, um das SecurityHub-Finding mit einer Notiz zu ergänzen, die den/die Namen des/der DRS-Quellservers mit Malware enthält.

Die SQS-FIFO-Warteschlangen können mit den Metriken Messages available und Message in flight aus der AWS SQS-Konsole überwacht werden.

Die DynamoDB-Tabellen für DRS-Volume-Annotationen verfolgen den Status jedes Malware-Scan-Vorgangs.

Amazon GuardDuty hat dokumentierte Gründe, Scan-Vorgänge zu überspringen. Weitere Informationen finden Sie unter Reasons for skipping resource during malware scan.

Um Logs von Amazon GuardDuty-Malware-Scan-Vorgängen zu analysieren, können Sie die Amazon CloudWatch-Loggruppe /aws/guardduty/malware-scan-events überprüfen. Die standardmäßige Aufbewahrungsdauer für diese Loggruppe beträgt 90 Tage, danach werden die Log-Ereignisse automatisch gelöscht.

Bereinigung

  1. Führen Sie die folgenden Befehle in Ihrem Terminal aus:

    root@kitploit:~
    cdk destroy --all
    
  2. (Optional) Löschen Sie die mit Lambda-Funktionen verbundenen CloudWatch-Loggruppen.

AWS-Kostenschätzungsanalyse

Für diese Analyse haben wir ein fiktives Szenario als Beispiel angenommen. Die folgenden Kostenschätzungen basieren auf Diensten in der Region Nord-Virginia (us-east-1).

Geschätztes Szenario:

  • 2 Quellserver zur Replikation (DR) (Gesamtspeicher: 100 GB - 4 Festplatten)
  • 3 TB Malware-Scan pro Monat
  • 30 Tage Aufbewahrungszeitraum für EBS-Snapshots
  • Tägliche Malware-Scans
Monthly CostTotal Cost for 12 Months
171.22 USD2,054.74 USD

Aufschlüsselung der Dienste:

DienstnameBeschreibungMonatliche Kosten (USD)
AWS Elastic Disaster Recovery2 Quellserver / 1 Replikationsserver / 4 Festplatten / 100 GB / 30 Tage Aufbewahrungszeitraum für EBS-Snapshots71.41
Amazon GuardDuty3 TB Malware-Scan pro Monat94.56
Amazon DynamoDB100 MB 1 Lesevorgang/Sekunde 1 Schreibvorgang/Sekunde3.65
AWS Security Hub1 Konto / 100 Sicherheitsprüfungen / 1000 erfasste Erkenntnisse0.10
AWS EventBridge1 Mio. benutzerdefinierte Ereignisse1.00
Amazon Cloudwatch1 GB erfasst/pro Monat0.50
AWS Lambda5 ARM Lambda-Funktionen - 128 MB / 10 Sek.0.00
Amazon SQS2 SQS-FIFO0.00
Gesamt171.22

Hinweis Die hier dargestellten Zahlen sind Schätzungen basierend auf den oben beschriebenen Annahmen, abgeleitet vom AWS Pricing Calculator. Weitere Details finden Sie in diesem Pricing Calculator als Referenz. Sie können die Dienstkonfigurationen im genannten Rechner anpassen, um Ihre eigene Schätzung zu erstellen. Diese Schätzung enthält keine möglichen Steuern oder zusätzlichen Gebühren, die anfallen könnten. Es ist wichtig zu beachten, dass die tatsächlichen Kosten je nach Nutzung und allen zusätzlichen, nicht in dieser Analyse abgedeckten Diensten variieren können. Für kritische Umgebungen wird empfohlen, den Business Support Plan einzuschließen (in der Schätzung nicht berücksichtigt).

Sicherheit

Weitere Informationen finden Sie unter CONTRIBUTING.

Autoren

  • Rodrigo Monge
  • Thierry Francois
  • Diego Pérez Holguín
  • Leandro Santi

Lizenz

Dieser Beispielcode ist unter der MIT-0-Lizenz lizenziert. Siehe die Datei LICENSE.

Tool herunterladen