Michael's DFIR Blog

Exploring Digital Forensics, Incident Response, Programming, and more

recent posts

  • Testing KaliGPT: Penetration Testing AI Assistant

    Official Kali wallpaper showing the Kali Linux logo

    One particularly hot topic around the security community recently is the use of LLMs and various other AI tools in cybersecurity – by red teams, penetration testers, blue teams, cyber criminals, and anyone and everyone interested in surreptitious access to computer systems. While looking at some of the more popular AI tools designed for cybersecurity engagements, I stumbled onto one I hadn’t encountered yet, Yashab Alam’s KaliGPT. Intrigued by the premise of a Kali-tailored AI assistant, I decided to download it onto a virtual machine running Kali and give it a go.

    With that out of the way, I started with a quick setup of a standard Kali image on Virtualbox. The installation of KaliGPT is pretty easy from the repository, with a simple script from the repo getting you quickly up and running. Only one small hiccup along the way – I forgot to create and initialize a virtual environment for python before I started and so it threw a couple of errors.

    KaliGPT Installation Script output showing options to install the Desktop GUI, Web GUI, CLI, or all of the above.

    Unfortunately this is where some problems start – I ran into a repeat Python issue that prevented anything but the CLI interface from launching properly, and an immediate roadblock where any request was met with a 500 status code. Doing some quick googling, this was probably an issue with inadequate RAM for running the model – something that could probably do with being added to the repository, but in general one should provision VMs that are going to be running LLMs with a decent amount of RAM. Increasing to the recommended amount of RAM for llama2 (I do not have API keys for the more advanced models, and wanted to try this bone-stock), I gave it another go.

    Unfortunately, even after getting it to work in the command line form, I still ran into issues – namely that any actual question I posed to the tool resulted in an HTTP timeout (as shown above). There is some tuning that could be done here – this is a VM running without a dedicated GPU, so maybe it just needs an adjustment in the timeout setting (or a GPU), so I can’t entirely pin this one on KaliGPT. I decided to give it a fair shake and ask it for some SQLI and XSS payloads, given that that is another suggested command in the documentation. Note that I attempted the suggested question from the help document (“what is sql injection”) again, receiving the same timeout error.

    Here, I did get it to successfully generate some basic payloads, and it does provide a few. While these are valid SQLI and XSS payloads, they aren’t anything beyond what a cursory Google search will provide you – pretty basic for the effort of installing the model.

    Here is where I think this runs into a bit of a problem – I, as someone who has only done cursory dabbling with ollama, can follow the installation instructions and get the tool set up on Kali but immediately run into issues that require further troubleshooting before I can get much use out of it. For the moment, I’ll leave it here – there’s some Python debugging I need to do with this to figure out exactly why it’s throwing the error that it is, as well as some possibility with the addition of API keys for better models instead of just running off the local model, but for a first pass it feels more like a novelty than a useful penetration testing tool.

  • Security+

    I’ve been studying for the past few months for my Security+, worried about making sure I filled the knowledge gaps I might’ve had to get a decent score. As of this morning, I’m finally finished and certified with a 792. Not the best score possible, but a passing score nonetheless! I figured I would throw some thoughts down in case any of my readers are thinking of getting the certification and wondering what sort of study materials to go through.

    Most of the time I spent was going through Darril Gibson’s “Get Certified, Get Ahead” study guide – designed for the previous SYO-601 version of the test, but still relevant to the content in the SYO-701. The book is a bit dense at times, but covers the topics on the test pretty thoroughly, at least enough to get you most of the way there with some additional work.

    Secondly, I used Professor Messer’s course – primarily primarily his practice tests. Going through and making note of subjects that I missed questions on, then watching his videos and reading the course notes really helped cement some subjects on the test I was weaker on. There’s a decent amount of video there – around 15 hours of total coverage, which will take you a bit to cover and completely absorb depending on how familiar you are with the subject matter. It’s invaluably good as a study guide, though.

    I attempted using the official CompTIA study material as well through the education store, however it didn’t quite click for me. The videos weren’t quite as engaging as Professor Messer’s course, and a bit tedious to get through. Not that they won’t work for you, but they weren’t really worth it for me. Reminder as well that a .edu email address gets you the education discount on a voucher, as well.

    What’s next? Splunk Power User and CCNA probably, but for now I take a bit of a study break. Stay tuned!

  • Dynamic Analysis: locky.7z

    This is a dynamic analysis conducted on a malware sample (named locky.7z) provided during a class of mine. This writeup is an adaptation of the lab report I wrote for this class to note down what I learned and explore the malware sample.

    To begin with, I downloaded the sample onto an airgapped system running Mandiant’s FLARE virtual machine. I extracted the sample from the 7z file to the desktop and started by investigating whether or not a packer had been used to obfuscate the code. To do so, I started by loading it into Detect it Easy and scanned the file, as shown below:

    Examining the results, we can see that there are three sections identified as packed by DIE, though no obvious information about what packer might have been used. To attempt to go deeper, I ran the malware through Universal Extractor, which threw an error indicating that the malware might contain a 7z archive (annoying, but a vital piece of information in the puzzle). Moving over to 7zip, I opened the executable file and found the contents:

    Taking the unpacked malware, I threw the contents into Ghidra to attempt to get a better idea of what it might do. Specifically, I took a look at the imports table to try and get an idea of what functions the sample was importing from Windows libraries. Below are the results: the malware imports the DLLs ADVAPI32, COMCTL32, GDI32, IPHLPAPI, KERNEL32, MSIMG32, MSVCRT, OLE32, OLEAUT32, OLEDLG, PSAPI, SHELL32, SHLWAPI, USER32, USERENV, VERSION, WINHTTP, and WTSAPI32.

    Examining this list, there are a few libraries that immediately caught my attention, starting with WTSAPI32.dll, which handles Remote Desktop services for Windows. Expanding WTSAPI32, there are two functions imported: WTSEnumerateSessionsW and WTSFreeMemory. WTSEnumerateSessionsW is a built-in Windows function that retrieves a list of all the sessions on a Remote Desktop Session Host server, while WTSFreeMemory will free up memory allocated by a Remote Desktop Services function. The two of these functions imply that the malware is potentially interacting with Remote Desktop Services, either starting a session with the attacker or attempting to read and steal information for further exploitation or to find the potentially sensitive files related to existing sessions on the victim system. Given that none of the other functions are imported, I believe that this is attempting to find sensitive information either for other computers on the network or for sessions on the victim system itself.

    Next is ADVAPI32.dll, which is a library that provides security calls and functions relating to the Windows registry. This lends itself to doing major damage to the system. A variety of functions are imported from the DLL by the malware, most interestingly those that handle looking up security info, manipulating the registry, and creating or deleting services – all of which could potentially be used to damage the system and steal sensitive data.

    Continuing the analysis, I had a look over the functions that Ghidra had built out while decompiling the malware. There is one particular function, “FUN_0040246c”, that appears to contain the main functions of the malware. This function takes the output of “FUN_00402a5f”, itself started by the “entry” function, as shown below. The outgoing calls from this function (bottom picture) seem to handle examining the system the malware is running on (tGetCurrentThread, GetVersion, RegOpenKeyW etc.).

    Based off the imports and functions in the malware, it is at least capable of reading, writing, and manipulating files, examining processes on the system, reading and modifying the registry, and accessing deep levels of system data – including looking into remote desktop sessions that the victim may be hosting. The access afforded by kernel and video-related DLLs (such as GDI32.dll) implies that the software is potentially capable of messaging the user or altering displayed information. Finally, the internet capabilities from WINHTTP.DLL implies that the malware is capable of accessing the internet, manipulating the user’s ability to access the internet, or at least monitoring the user’s internet activity.

    This isn’t a complete examination, but I hope it was at least interesting to read along with my work!

  • Greetings from the DMV

    Hello, readers! I am a Digital Forensics grad student working in cybersecurity in the DMV area – this blog will be a place for me to post analysis and thoughts on DFIR topics, programming, and other related projects as I continue through my professional journey. Feel free to tag along!