Kategorie: Weiterbildung

Allgemein, Forensics, Weiterbildung

A Tale of Practical Keylogger Forensics

On a recent engagement, an interesting hardware side quest popped up. A client had found a keylogger and, naturally, we wanted to know what the adversary had seen and if we could gather any useful traces towards the perpetrator.

Since our analysis included some twists, we decided to document parts of our process to perform a forensic analysis on a keylogger. We hope to shed some light on the forensic possibilities and encourage others to expirement with similar hardware.

Passive Reconnaissance

Hardware keyloggers come in various shapes and sizes. The one we got, that was yanked from a computer in a public area, was no larger than a fingernail. To some surprise it was 3D printed, as the layers were visible.

Of course, our first goal was be to identify the device in front of us. What is it capable of? Is there any sort of documentation we can leverage? And although it looks just like any other keylogger, we started with some passive reconnaissance to confirm our first assumption.

To our amusement, finding the exact model and documentation was just a single image search away. Simply taking a picture and using reverse image search, we immediately identified the „KeyGrabber Air“.

At this point we had a rough idea of what this device could do. Most notably, it could be used for:

  • Capturing and storing keystrokes (no injection)
  • Open a WLAN to host a web interface that shows settings and keystrokes
  • Connect to a WLAN to send keystrokes via FTP or SMTP

Active Reconnaissance

After powering on the device via the USB port, we noticed a new WLAN appear with the SSID „AP001“. This matched the documentation we found earlier. However, the network required a password and it was neither a common password such as „password“ or any other default credential we could find in the documentation. We also could not identity any sort of key combination (such as K+B+S) that would grant us administrative access, as it has been the case with other keyloggers.

Hence, we asked for permission to apply some more intrusive techniques. Once we received a thumbs up from the client, we opened the case and got to the circuitry.

As the figure above shows, there are only two core components on the board. On the bottom left you can see an ATMEL AT91SAM7S32 MU and on the right an ESP8285. The data lines from the USB ports are directly connected to the AT91SAM7S32, which indicates that this chip may be responsible for parsing the differential signals and extracting the key values. Of more interest to us is the ESP8285 which is a common chip for wireless applications and also connects to a small antenna on the PCB.

Unfortunately, neither the connectors (golden circles) in the middle, nor a direct connection with a Sensepeek PCBite to the ESP gave us access to the chip. Our assumption is that the passive components and connections on the board interfered with our attempts to communicate with the ESP8285 directly.

Our goal was to hook up to UART, the debug interface of the chip, to dump its memory. Thus, we once again asked for permission to proceed and were given the green light to desolder the ESP. Word of caution: make sure to check the datasheet of the components you want to desolder for allowed temperatures in advance to avoid the risk of damaging anything. A small nozzle and a rather low airflow prevents the passive components on the side from getting blown away. I can also recommend preheating the board, to heat large ground pads.

Since the ESP is tiny and needs some passive components to function, we decided that it would be easiest to just install it on a developer board for easy access. Thus, we got ourselves a cheap dev-kit like this:

This set exposes the UART interface (board on the right) and includes a UART to USB converter (left).

We desoldered the original chip, replaced it with the one we got from the keylogger and connected the board to a computer. Now, we could use esptool to finally dump the memory of the ESP. Note that the ESP8285 has an internal flash memory. Other chips may use an external flash chip, so you may be able to access the storage directly and don’t need to deal with the ESP/esptool.

With esptool we need the Baudrate (115200 is the default for this chip), the path to the USB device, the command (read_flash), a start address (0), the amount of bytes to read (in case of the ESP8285 flash that is 1 Megabyte) and a filename to store the contents.

$ esptool -b 115200 --port /dev/ttyUSB0 read_flash 0x0 0x100000 flash_1M_esp.bin
espool.py v4.7.0
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again
Connecting...
Detecting chip type... ESP8266
Chip is ESP8285H16
Features: WiFi, Embedded Flash
Crystal is 26MHz
Uploading stub...
Running stub...
Stub running...
315392 (30%)

When esptool finished without errors, we had the entire flash content in a file.

Analysing the dump

As with any other binary file, we can save ourselves alot of trouble by just extracting all readable strings and start analysing them, before doing any reversing. However, the strings output on the binary showed tons of:

[N][+N][+N][+N]´[+N]´[+N][+N]´[+N][+N][+N][+N][+N]dckjhe^[+N]´x[+N]´[+N]´c[+N]´[+N]´[+N][+N][+N]a,[+N][F5]x[+N][+N][+N][+N]a,bsc[+N]a,[+N][+N][+N][+N]a,a,[+N][+N][+N][+N]a,[+N]c´[+N][+N][+N][+N]e^dc[+N][+N][+N][+N]´[+N][+N][+N][+N][+N][+N][+N][+N][+N][+N][+N]xx´[+N][+N][+N]bs[+N]a,a,[+N]c[+N][+N][+N]a,[+N][+N]c[+N][+N]a,[+N]bsa,[+N]´[+N]´[+N][+N]´[+N]´´[+N][+N][+N][+N][+N][+N]a,[+N][+N][+N]bsa,a,[+N]a,[+N][+N][+N][+N][+N]a,[+N]a,[+N][+N][+N]´[+N][+N][+N][+N]´[+N]´[+N]´[+N][+N]bsa,[+N]´[+N][+N][+N][+N]´[+N][+N][+N][+N][+N][+N]´[+N]a,[+N][+N][+N][+N]´[+N][+N][+N][+N][+N][+N]a,[+N][+N][+N][+N][+N][+N][+N][+N][+N]a,[+N][+N]´[+N][+N][+N][+N][+N][+N][+N][+N][+N][+N][+N][+N][+N][+N][+N][+N][+N][+N]
[+N]x[PUp][+N][+N][+N][+N]bsa,bs[+N][+N]a,bs[+N]c[+N][+N]´[+N][+N]´[+N][+N][+N]a,[+N]ca,

At first we were optimistic. There were strings like [LCtrl][Rgh]cbscbs[+N][LCtrl] which seemed like valid keystrokes. But the longer we studied the output, we could only make less and less sense of it. We thought, maybe the contents were encoded or maybe the memory got corrupted along the way.

The initial feeling of success was followed by the depressing realisation that the output was useless. However, motivation quickly came back when we found the following intact and readable configuration in the strings output:

ap_name
AP001
ap_password
*******[redacted]

Unfortunately, it did not appear as if the adversary had specified any FTP or SMTP credentials. This could have been a great finding and a hint towards the identity of the perpetrator. However, equipped with the WiFi password, we would finally be able to access the keylogger dashboard.

Beware of rabbit holes. For quite some time we believed that the ESP firmware may hold some value and potentially we could decode the magic log strings when we just reversed the application. We would just have to convert the binary back to an ELF and then apply Ghidra. In hindsight, that step was completely unnecessary and although we learned quite a bit about ESPs and ELFs, it was not nearly as efficient as what we did next.

Put everything back together

We desoldered the ESP from the dev-board and put it back on the keylogger. At last, we successfully connected to the WLAN of the keylogger. Following another quick read of the documentation, we navigated to http://192.168.5.1 and finally:

This was not what we anticipated. Either we had corrupted the filesystem or something weird was going on. Every page of logged keystrokes contained nothing but nonsense. However, the configuration we extracted was intact. And indeed, the dashboard displays all data as we would expect.

Even the keyboard language was setup correctly. Still, apart from the WiFi password, we had no valuable insights for the investigation. And then a random idea struck. What if the adversary had mixed up the USB devices and plugged in a mouse instead of a keyboard?

So we placed the keylogger in a test environment, plugged in a keyboard and to our surprise it was logging without a single fault. Even bigger was the relief, when we plugged in a mouse – moved and clicked it a few times – and looked at the logs again:

Only for the last two lines, we plugged in the mouse. And the output we see (notably lots of [LCtrl] and [+N]) shows significant similarities to the entire previous log.

At this point, we assessed, that the perpetrator most likely did not exfiltrate any useful information this way. Instead, with a high chance the keylogger was plugged in to USB device other than an ordinary keyboard.

Key Learnings

Keylogger forensics could uncover valuable information. Additionally, the process can be fairly straight forward. In this scenario we did not have to circumvent any physical protection mechanisms.

  • Keep it simple (reverse image searching for a simple photo of the keylogger led us straight to the relevant documentation)
  • Even though the default password was changed, retrieving it from the keylogger was as easy as running strings on the memory dump
  • Dumping the memory also allowed us to extract unencrypted log files and keylogger settings immediately
  • The keylogger configuration may contain some interesting information such as credentials for SMTP, FTP or a WiFi hotspot that could lead you straight to the adversary
  • Adversaries make mistakes too, for example placing a keylogger between a computer and the mouse cable

Risikomanagement, Veranstaltungen, Weiterbildung

Die Sommerlücken kommen

Während im ersten Bundesland die Sommerferien schon wieder vorbei sind, beginnt diese Woche die Sommersaison der Sicherheitskonferenzen: eine Serie von spektakulären Ankündigungen und tatsächlich auch spektakulären Neuigkeiten in der Security. Den Anfang machen die amerikanischen Konferenzen DEFCON, Blackhat US und BSidesLV – die praktischerweise alle in Las Vegas nach- und nebeneinander stattfinden. Daher wird der Block auch gern „Hacker Summer Camp“ genannt, obwohl alles drinnen stattfindet. Die akademischere Welt trifft sich in Anaheim zum USENIX Security Symposium und in Europa verabredet man sich in echten Zelten: Erst beim großen Chaos Communication Camp in der Nähe von Berlin und dann bei kleineren Camps wie dem Hacken Open Air in Gifhorn.

Bei vielen Darbietungen werden die Details erst im Vortrag selbst enthüllt und führen dann schnell zu spektakulären Schlagzeilen. Manchmal sind Schlagzeile und Vortrag spektakulärer als das sich tatsächlich für die Praxis ergebene Risiko, aber nicht selten sind auch wegweisende Entwicklungen dabei. Wenn Sie diesen Digest lesen, dann haben Sie vielleicht schon die ersten Nachfragen zu einigen Schlagzeilen im Postfach.

Zwei Themen machten schon im Vorfeld Schlagzeilen:

  • Mehrere Schwachstellen wurden im TETRA Funkstandard entdeckt. Die Detailbeschreibungen teilten die Entdecker nicht nur auf die oben genannten Konferenzen, sondern auf insgesamt fünf verschiedene Vorträge auf. TETRA kommt hierzulande vor allem als BOS-Funk zum Einsatz (für Behörden und Organisationen mit Sicherheitsaufgaben). Durch die Art und Weise des Einsatzes und vor allem durch zusätzliche Ende-zu-Ende-Verschlüsselung sind diese nicht betroffen.
  • Forscher der TU Berlin zeigen, wie sie die zentrale Entertainmentsteuereinheit eines Tesla übernehmen konnten. „Entertainment“ klingt im ersten Moment nicht spektakulär, beinhaltet aber beispielsweise die geregelte Freischaltung von Fahrzeugfunktionen, die nur über zusätzliche Abos verfügbar sind – wie die Sitzheizung. Den Forschern gelang außerdem der Zugriff auf Schlüssel, mit denen sich das Fahrzeug bei den diversen Onlinefunktionen gegenüber dem Hersteller ausweist.

Neben den Vorträgen gibt es auch immer diverse andere Programmpunkte, unter anderem Wettbewerbe. Besonders spektakulär ist diesmal der Hack-a-Sat-CTF, für dessen Finalrunde extra am 7. Juli ein eigener Satellit in die Umlaufbahn gestartet wurde.

Die einzelnen Konferenzprogramme finden sich hier:

Weiterbildung

Firmen buhlen um IT-Sicherheitsfachkräfte

Einzelmaßnahmen werden nicht ausreichen.

„Der deutsche Security-Markt steht aktuell unter den Zeichen eines akuten Fachkräftemangels und der neuen Datenschutz-Grundverordnung DSGVO“

ISG Provider Lens™ Study – Cyber Security Solutions & Services 2019

Seit Jahren zeichnet sich ein Defizit an Sicherheitsfachleuten ab – nicht nur in Deutschland, sondern weltweit. So prognostiziert ISC² in seiner aktuellen Cybersecurity Workforce Studie:

„The Asia/Pacific region is suffering from the largest shortfall of about 2.14 million with North America having the next biggest need with 498,000 workers needed, then EMEA at 142,000 and Latin America at 136,000.“

(ISC)² Cybersecurity Workforce Study 2018

Firmen und Organisationen versuchen nun, diese Lücken individuell zu schließen. Dazu gehören Ersatzmaßnahmen wie Bug-Bounty-Programme, bei denen die Organisation die Suche und Identifikation von Sicherheitslücken an Dritte verlagert.

Weitere Aktionen zielen auf die Identifikation und Förderung von Nachwuchs im Rahmen von Hacking-Wettbewerben oder Einrichtung von Center of Expertise.

All diese Maßnahmen zielen primär auf eher technisch orientierte Mitarbeiter, z. B. Penetrationstester oder Softwareentwickler. Dabei werden in Sicherheitsumfeld noch weitere Experten gesucht, z. B. Spezialisten, die ein unternehmensweite Sicherheitsmanagement konzeptionieren, dokumentieren und im laufenden Betrieb pflegen oder Generalisten, die die gefundenen Schwachstellen mit den betrieblichen Belangen in Zusammenhang bringen und die sich daraus ergebenden Risiken bewerten.
Hinzu kommt noch, dass die Aufgaben und Anforderungen an eine Sicherheitsfachkraft in der Firma A unterschiedlich zu denen in Firma B sind, auch wenn die Stellenbeschreibungen und Stellentitel durchaus identisch klingen.

Andere Wege werden nun in den USA eingeschlagen. In der NIST Special Publication SP 800-181 wird im Rahmen der National Initiative for Cybersecurity Education (NICE) ein umfangreiches „Cybersecurity Workforce Framework beschrieben, das im Detail die Bereiche, Rollenbezeichnungen und Aufgaben der verschiedenen Rollen in einer Security-Organisation beschreibt. Weiterhin sind zu jeder dieser Rolle auch das erforderliche Wissen und die Fähigkeiten aufgelistet.

Diese umfangreiche Standardisierung soll es einmal den Arbeitgebern erleichtern, die internen Positionen mit geeignetem Personal zu besetzen.
Gleichzeitig wird den Mitarbeitern und Ausbildungsinstitutionen die erforderlichen Anforderungen an bestimmte Rollen eindeutig mitgeteilt, so dass sich potentielle Kandidaten bereits im Vorfeld entsprechen schulen können und sich idealerweise nur für die Positionen bewerben, die ihrem Wissen und den Fähigkeiten entsprechen.

Mit diesem Framework ergeben sich nun vielfältige Möglichkeiten und Vorteile für alle Beteiligten. Ein Beispiel für das Einsatzfeld der Informationen aus dem NICE Framework finden sich auf dem Portal von Cyberseek.org. Dieses Portal stellt Arbeitgebern und Stellensuchenden, aber auch Ausbildungsstätten und anderen Interessierten verwertbare Informationen über den Cybersecurity-Stellenmarkt (in den USA) zur Verfügung.

Dazu bietet das Portal im Moment zwei interaktive Anwendungen:

  1. Cybersecurity Career Pathway – informiert den Interessenten über typische Cybersecurity-Rollen und die dazugehörigen Karrieremöglichkeiten inklusive aktuell offene Positionen und Durchschnittsgehalt auf Basis des NICE-Frameworks.
  2. Cybersecurity Workforce Heat Map – gibt dem Stellensuchendem einen geographischen Überblick über den Stellenmarkt und gesuchte Positionen inklusive den dazugehörigen Fähigkeiten auf Basis des NICE-Frameworks.

Cybersecurity Supply/Demand Heat Map (CyberSeek)

Fazit

Um den Fachkräftemangel im IT-Security-Umfeld zu minimieren, bedarf es zuerst einer einheitlichen Definition der Aufgaben, Fähigkeiten und Fertigkeiten. Dieser Standard kann dynamisch erweitert werden und als Basis für weitere Anwendungen genutzt werden, was sowohl den Organisationen, aber auch den stellensuchenden Interessenten entgegenkommt.