Akustikkoppler

Archive for Mai 2022

pagefile.sys-Forensik: Vorsicht vor Yara Fehlalarmen durch Microsoft Defender-Artefakte

Da ich mich nun viel mit Forensik unter Verwendung von Open-Source-Tools beschäftige, bin ich auf Andrea Fortunas Seite mit vielen nützlichen Informationen gestoßen. In einem Fall liegt er jedoch (nun) leider falsch. Das hängt möglicherweise von der Windows 10 Version ab. Ich habe hier Win10 Edu 21H2 für meine Untersuchung verwendet. Da Andrea Fortunas Seite scheinbar der einzige Hinweis auf technische Infos zum Thema pagefile.sys Forensik mit yara  von Virustotal ist, möchte ich das hier für interessierte Leser korrigieren, um false positive zu verhindern. Hier sind Andreas Fortunas Infos dazu zu finden:
https://andreafortuna.org/2019/04/17/how-to-extract-forensic-artifacts-from-pagefile-sys/

Die dort beschrieben Anwendung von yara und eines Scans nach URL-Artefakten mit “strings” führen zu Fehlalarmen, die durch Microsoft Defender-Speicherartefakte durch Malware-Signaturen verursacht werden, selbst bei einem frisch installierten Windows:
Yara findet bei mir (frisch installiertes Windows 10, gerade mal 5 Minuten mit dem Internet verbunden):
APT1_LIGHTBOLT pagefile.sys
Tofu_Backdoor pagefile.sys
APT9002Code pagefile.sys
APT9002Strings pagefile.sys
APT9002 pagefile.sys
Cobalt_functions pagefile.sys
NK_SSL_PROXY pagefile.sys
Industroyer_Malware_1 pagefile.sys
Industroyer_Malware_2 pagefile.sys
malware_red_leaves_memory pagefile.sys
GEN_PowerShell pagefile.sys
SharedStrings pagefile.sys
Trojan_W32_Gh0stMiancha_1_0_0 pagefile.sys
spyeye pagefile.sys
with_sqlite pagefile.sys
MALW_trickbot_bankBot pagefile.sys
XMRIG_Miner pagefile.sys
Ursnif pagefile.sys
easterjackpos pagefile.sys
Bolonyokte pagefile.sys
Cerberus pagefile.sys
DarkComet_1 pagefile.sys
xtreme_rat pagefile.sys
xtremrat pagefile.sys

Was definitiv falsch positiv ist!
Ich habe die malware_index.yar von
wget https://github.com/Yara-Rules/rules/archive/refs/heads/master.zip

verwendet.

Selbst wenn das frisch installierte Windows 10 vorher vollständig vom Netzwerk isoliert war, findet yara schon einige Artefakte:
APT1_LIGHTBOLT pagefile.sys
GEN_PowerShell pagefile.sys
with_sqlite pagefile.sys
Bolonyokte pagefile.sys
Die Liste der extrahierten URLs mit dem Unix-Befehl “strings”

$ strings pagefile.sys | egrep "^https?://" | sort | uniq > url_findings.txt

wird unter Windows selbst als Malware erkannt, weil dort Malware-URLs gefunden werden, wenn die Maschine jemals mit dem Netz verbunden war ;-). Ohne Netz finden sich keine Malware URLs. Meine Vermutung war, dass der Ursprung des Malware-Artefakts der Windows Defender war. Für die Malware URLs kann aber auch “safe browsing” im Edge die Ursache sein. Um dies zu klären, habe ich einige Experimente durchgeführt.
Da der Windows Defender ein integraler Bestandteil von Windows 10 und 11 ist, ist es nicht einfach, den Windows Defender bei einer Neuinstallation vollständig zu entfernen. Alle Anleitungen, die ich gefunden habe, funktionierten mit den aktuellen Windows 10 Versionen seit 21H2 nicht mehr. Schließlich habe ich ein PowerShell-Skript auf Jeremy Website bidouillesecurity.com gefunden:
https://bidouillesecurity.com/disable-windows-defender-in-powershell/
Danach habe ich die pagefile.sys einmal komplett geschreddert, damit sicher ist, dass keine Artefakte zurück bleiben. Allerdings versucht Windows Update auch dann nach Anwendung  dieses Skriptes, Malware-Signaturen herunterzuladen, die dann wieder als Artefaktes in der pagefile.sys landen. Nur wenn ich den Internetzugang der neu erstellten Installation komplett sperre, erscheinen keine Malware-Artefakte mehr in der pagefile.sys. Auch das Deaktivieren von Windows-Updates ist heutzutage keine leichte Aufgabe mehr. Einfach die Ethernet-Verbindung auf “metered connection” (im Deutschen “getaktete Verbindung”) zu stellen, funktioniert in den aktuellen Versionen nicht mehr. (Warum auch immer, Zitat aus 2001, Odyssee im Weltraum: Ich kann dich das nicht tun lassen Dave
Für meine Experimente habe ich virtuelle Maschinen im VMWare Player unter Linux erstellt, die VMDK-Images mit qemu in das Raw-Format konvertiert und die pagefile.sys aus dem Image für die Forensik entnommen.
qemu-img convert -p -O raw /pfad/meinWin10.vmdk vm.raw
Das loop device intitialisieren:
losetup /dev/loop100 -P vm.raw
Option P nach Paritionen scannen, loop device loop100 erzwingen (-f zeigt das nächste freie Gerät, aber loop100 sollte immer frei sein)
Mounten dss Images:
mount /dev/loop100p3 /mnt/image
Kopieren:
cp /mnt/image/pagefile.sys .
Yara scannen:
yara /home/bischoff/yara-rules/rules-master/malware_index.yar pagefile.sys > yara_neu.log
URL-Extraktion:
strings pagefile.sys | egrep "^https?://" | sort | uniq > alle_urls.txt
Um die ursprüngliche pagefile.sys vollständig zu löschen (zu schreddern und um zu verhindern, dass Plattenplatz einfach wieder alloziert und nicht wirklich gelöscht wird, habe ich folgenden Befehl verwendet:
shred -uvz /mnt/image/pagefile.sys
Unmounten des Images und Entkoppeln des Loop-Devices:
umount /mnt/image
losetup -d /dev/loop100
Konvertieren des Roh-Images zurück in ein VMWare-Image:
qemu-img convert -p -O vmdk vm.raw /pfad/meinWin10.vmdk

Auch mit obigem Powershell-Script, also deaktiviertem Defender, holt sich das Windows Update offensichtlich immer wieder neue Signaturen, sobald eine Verbindung zum Internet besteht.
Selbst wenn man an keinen Speicherauszug eines infizierten Rechners herankommt, liefert eine hyberfile.sys oder eine pagegefile.sys dem Forensiker indirekte Informationen über den Speicherinhalt. Vorsicht ist jedoch geboten bei Defender-Artefakten, die zu falsch positiven Erkennungen führen können.

Ein altes Mediawiki umziehen, ein Mediawiki-Offline-Backup mit httrack erzeugen und Tipps für eine Confluence-Migration mit dem Ziel Mediawiki

Durch den Erfolg der Wikipedia ist die Mediawiki-Software sehr bekannt geworden und an vielen Orten im Einsatz. Da so ein Mediawiki gut funktioniert und die Tendenz hat zu wachsen, wenn fleißige Leute an den Inhalten mitarbeiten, stellt sich irgendwann die Frage nach einer Migration auf einen neuen Server.
Im Gegensatz zu vielen PHP-basierten Anwendungen ist es häufig nicht möglich, bei einer Neuinstallation einfach die alte Datenbank für die neue Installation zu übernehmen. Das hängt damit zusammen, dass das Mediawiki kontinuierlich weiterentwickelt worden ist, was an der Oberfläche (glücklicherweise) nicht zu erkennen ist.
Der Erfolg vom Mediawiki hängt gerade an dieser einfachen Oberfläche. Das ist aber auch ein Kritikpunk bzw. der Grund für noch einfacher (auch für Leute die schon von der Mediawiki-Syntax überfordert sind) bedienbare kommerzielle Alternativen wie z.B. Atlassian Confluence, das aber in Zukunft nur noch in der Cloud angeboten wird, was die Zahl von Mediawiki-Installationen im Geltungsbereich der DSGVO sicher in die Höhe treiben wird. Wer mal in die Bredouille kommt, so etwas realisieren zu müssen, dem können diese Infos hier helfen:
https://bluespice.com/de/migration-von-confluence-nach-bluespice-mediawiki/
Bluespice hat dankenswerterweise seine Migrationsscripte auf GitHub zur Verfügung gestellt:
https://github.com/hallowelt/migrate-confluence
Glücklicherweise bietet auch eine ältere Mediawiki-Installation vielfältige Möglichkeiten die Inhalte im XML-Format zu exportieren, dass ein ganz aktuelles Mediawiki wieder importieren kann. Ähnlich wird übrigens auch bei einer Confluence zu Mediawiki Migration vorgegangen (siehe oben im Github-Link).
Mediawiki Grundinstallation auf einem neuen Server (hier ein Ubuntu-Server 20.4LTS):

sudo apt-get install apache2 mariadb-server -y
sudo  apt-get install php libapache2-mod-php php-common \
php-mbstring php-xmlrpc php-soap php-gd php-xml php-intl \
php-mysql php-cli php-mcrypt php-zip php-curl -y
sudo apt-get install php libapache2-mod-php php-common \
php-mbstring php-xmlrpc php-soap php-gd php-xml php-intl \
php-mysql php-cli  php-zip php-curl -y
sudo  apt install php-apcu
sudo systemctl start apache2
sudo systemctl enable apache2
sudo systemctl start mysql
sudo systemctl enable mysql
sudo mysql_secure_installation
mysql -u root -p
wget https://releases.wikimedia.org/mediawiki/1.36/mediawiki-1.36.1.tar.gz 
(immer eine aktuelle Version verwenden! Erst schauen unter https://releases.wikimedia.org/mediawiki/ )

cd /var/www/html/
tar -xvzf /home/itmc-admin/mediawiki-1.36.1.tar.gz
(use always newest version) 
mv mediawiki-1.36.1/ mediawiki
chown -R www-data:www-data /var/www/html/mediawiki
chmod -R 755 /var/www/html/mediawiki
chmod -R 755 /var/www/html/mediawiki
hostnamectl set-hostname [YOURHOSTNAME]
sudo apt-get install imagemagick

Dann die zentrale Konfigurationsdatei /var/www/html/mediawiki/LocalSettings.php anpassen und dem Apachen eine /etc/apache2/sites-available/mediawiki.conf bauen (ssl/Zertifikate usw.).
Beide Dateien sind stark abhängig von den lokalen Gegebenheiten.

Export der Inhalte auf dem alten Mediawiki:

Wegen des hohen Versionsunterschieds wurde der Weg über einen XML-Export gewählt.

In /mediawiki/maintenance

cd /srv/www/htdocs/mediawiki/
php dumpBackup.php  --full --quit > wikinamedump.xml

Dann wikinamedump.xml und das Verzeichnis “images” übertragen per scp auf die neue Maschine.

Importieren der alten Inhalte des Wikis auf der neuen Maschine:

User Anonymous anlegen (beliebiges PW) dann erst geht:

php importDump.php --conf ../LocalSettings.php  /home/itmc-admin/wikinamedump.xml --no-local-users

Images Verzeichnis übertragen und Rechte einstellen:

chmod -R 755 images

Dann in maintenance die Bilder in der Datenbank neu indizieren, die Wiki-Links updaten und einen Rebuild durchführen:

 

cd maintenance/
php importImages.php --dry --search-recursively /var/www/html/mediawiki/images/
php importImages.php  --search-recursively /var/www/html/mediawiki/images/
php refreshLinks.php
php update.php
php rebuildall.php

Manchmal kann eine lokale Sicherung eines Mediawikis Gold wert sein, insbesondere, wenn man dort seine IT-Umgebung dokumentiert. Klar, man kann das über einen lokalen Webserver und eine Datenbank laufen lassen, aber dass ist oft ein Overkill. Einen ganz sauberen PDF-Export eines größeren Mediawikis habe ich seit Jahren nicht mehr gesehen und da viel mir der wunderbare statische Website-Kopierer httrack ein. Ich war nicht der Erste mit der Idee und ich habe dazu diese
https://www-public.imtbs-tsp.eu/~berger_o/weblog/2008/05/30/offline-backup-mediawiki-with-httrack/
und diese Anleitung
https://github.com/oschrenk/scripts/blob/master/backup-mediawiki-de.sh
gefunden. Leider ist das „moderne“ Webdesign auch an den Mediawiki-Themes nicht spurlos vorbeigegangen. Developer moderner Frameworks finden es cool, das Laden von CSS-Dateien abhängig von Javascript-Code zu machen, der Parameter wie Seitenbreite des Fenster, Device usw. für responsive Design ermittelt. Ein statischer Website-Kopierer hat da natürlich verloren. Das Ergebnis sieht dann aus, als ob Stylesheets ganz abgeschaltet worden sind. „Erwachsene Browser“, oder Browser für Erwachsene, wie der Firefox ermöglichen es, so etwas unter „Ansicht“, „Webseiten-Stil“, „kein Stil“ zu erzwingen.
Da ich im Fall der statischen Kopie aber nicht auf die Formatierung verzichten möchte, habe ich die oben verlinkten Scripte so modifiziert, dass ich das Stylesheet des Mediawiki-Standardthemes per Loop in die generierten HTML-Seitern hinein mogele.
Installieren von httrack:
apt-get install httrack
Das Ganze mache ich automatisch regelmäßig per cron-job:

5 3 * * 7 /home/admin/backup-mediawiki-de.sh > /dev/null 2>&1

Als kleines Features wurden noch ein Zip-Archiv mit einem Passwort in das Script integriert.
Sonntags um 3:05 Uhr lasse ich das backup-Script /home/admin/backup-mediawiki-de.sh ausführen, welches folgenden Inhalt hat:

#! /bin/sh

# Inspired by blogpost from http://www-public.it-sudparis.eu/~berger_o/weblog/2008/05/30/offline-backup-mediawiki-with-httrack/
# And ttps://github.com/oschrenk/scripts/blob/master/backup-mediawiki-de.sh
# Modified for modern Mediawiki and zip-Backup, A.Bischoff

# -w            mirror web sites (--mirror)
# -O            backup directory
# -%P           extended parsing, attempt to parse all links, even in unknown tags or Javascript (%P0 don't use) (--extended-parsing[=N])
# -N0           Saves files like in site Site-structure (default)
# -s0           follow robots.txt and meta robots tags (0=never,1=sometimes,* 2=always) (--robots[=N])
# -p7           Expert options, priority mode: 7 > get html files before, then treat other files
# -S            Expert option, stay on the same directory
# -a            Expert option, stay on the same address
# -K0           keep original links (e.g. http://www.adr/link) (K0 *relative link, K absolute links, K3 absolute URI links) (--keep-links[=N]
# -A25000       maximum transfer rate in bytes/seconds (1000=1kb/s max) (--max-rate[=N])
# -F            user-agent field (-F "user-agent name") (--user-agent )
# -%s           update hacks: various hacks to limit re-transfers when updating (identical size, bogus response..) (--updatehack)
# -x            Build option, replace external html links by error pages
# -%x           Build option, do not include any password for external password protected websites (%x0 include) (--no-passwords)

site=YOURWIKIHOST
# YOURWIKIHOST z.B. www.wikipedia.de

sitepath=$site/mediawiki
topurl=https://$site/mediawiki/index.php
backupdir=/home/admin/wiki-backup/$site

echo "==== cleaning up ===="
echo
rm -r $backupdir

httrack -w $topurl/Spezial:Alle_Seiten \
-O "$backupdir" -%P -N0 -s0 -p7 -S -a -K0 -A999000 \
-F "Mozilla/4.5 (compatible; HTTrack 3.0x; Windows 98)" \
-%s -x -%x  \
"-$sitepath/Spezial:*" \
"+$sitepath/Spezial:Letzte_Änderungen" \
"-$sitepath/index.php?*" \
"-$sitepath/Diskussion:*" \
"-$sitepath/Benutzer_*" \
"-$sitepath/Kategorie_Diskussion_*" \
"+$sitepath/images/*" \
"+*.css"

echo "wget start"

for page in $(grep "link updated: $sitepath/index.php/" $backupdir/hts-log.txt | sed "s,^.*link updated: $sitepath/index.php/,," | sed "s/ ->.*//" | grep -v Spezial:)
do
wget -nv -O $backupdir/$sitepath/index.php/${page}_raw.txt "$topurl/index.php?index=$page&action=raw"
done

echo "wget done"

# Andreas repair css and js

wget -nv -O $backupdir/$sitepath/index.php/mediawiki.css "https://$site/mediawiki/load.php?lang=de&modules=skins.vector.styles.legacy&only=styles&skin=vect
wget -nv -O $backupdir/$sitepath/index.php/mediawiki.js "https:// $site/mediawiki/load.php?lang=de&modules=startup&only=scripts&raw=1&skin=vector"

FILES="$backupdir/$sitepath/index.php/*.html"
for html in $FILES
do
   echo "file: $html"
   sed -i -e  's|</head>|<link rel="stylesheet" href="mediawiki.css"/><script async="" src="mediawiki.js"></script></head>|' $html

done
#
# my html
cp /home/itmc-admin/index2.html  $backupdir/index.html
# Andreas Add Date
current_time=$(date "+%d.%m.%Y um %H:%M:%S Uhr")
sed -i -e  "s|<BODY>|<BODY><h1>Backup erzeugt durch cronjob am $current_time |"  $backupdir/index.html

# Andreas create ZIP File – cut here if you don’t need an zip Archive
# remove –passwort Option if the wiki content is public
rm  /home/admin/wiki-offline.zip
#cd $backupdir/mediawiki;
ln -s $backupdir /home/admin/wiki-offline
zip -r --password ******* /home/admin/wiki-offline.zip ./wiki-offline
rm /home/admin/wiki-offline
#cd /home/admin;
cp /home/admin/wiki-offline.zip /var/www/html/backup/

echo "geschafft"

 

Das Script ist an deutschsprachige Mediawiki-Installationen angepasst. Für andere Sprachen müssen die Links im Script für die sprachspezifischen Spezialseiten angepasst werden.
Wenn man das Script etwas modifiziert, kann das Script sicher auch für httrack-Abzüge von modernen WordPress-Sites verwendet werden. Relevant ist dann der Teil ab „# Andreas repair css and js“, der Links zu CSS- und Javascript-Dateien vor den abschließenden „head“-Tag ins HTML hineinoperiert. Wenn ich mal Lust habe, forke ich vielleicht httrack für eine Option auf der Kommandozeile, um direkt dort zusätzliche Javascript- und CSS-Links angeben zu können, die automatisch in jede Seite eingebaut werden.