Baker Street Forensics

Ginsu: A tool for repackaging large collections to traverse Windows Defender Live Response

Enterprise customers running Windows Defender for Endpoint have a lot of capability at their fingertips. This includes the Live Response console, a limited command shell to interact with any managed Defender assets that are online. Besides its native commands you can also use the console to push scripts and executables to endpoints.

Note: there is a specific security setting in the Defender console if you want to allow unsigned scripts.

Microsoft has its own triage package capability, but you can also push your own tools like Magnet RESPONSE or KAPE. With a little bit of PowerShell mojo you can use your favorite collection utilities using the Defender Live Response console as your entry point into the remote asset.

The console enables you to pull back files from the remote endpoint, even when it’s been quarantined. One limitation of this console function is that you’re limited to retrieving files of 3GB or less.

For many triage collections this could be under the limit, but depending on the artifacts you’re collecting you might exceed that. So what do you do when you have an isolated endpoint but you need to pull back files over 3GB? That’s where Ginsu comes in.

Ginsu is a PowerShell script that you can upload to your Defender console along with the command line version of 7zip. You configure the script with the directory with the contents you want to transfer. The script acts as a wrapper for 7zip and will create a multipart archive, splitting the files into 3GB segments.

Once you pull the archives back to your workstation, you can use 7zip to extract the files back into their original properties.

In testing, the file transfer capabilities were a bit buggy, whether it was transferring 3GB Ginsu files or other smaller files from the asset. I’m hoping this improves as the Defender console matures. If you’re able to text Ginsu in your environment, I’d love to hear how it performs.

You can download Ginsu from my GitHub repo at https://github.com/dwmetz/Ginsu

Installing REMnux on a MacBook Pro

DFIR, Forensics, Mac, Malware

I had an older MacBook Pro (15-inch, 2.53GHz, Mid 2009) that had been unused for a while as it was no longer getting updates from Apple. It’s one of the Intel chip ones and last ran Monterey. I pulled it out of the closet and decided to give it a refresh by installing REMnux on it. The process was pretty straightforward, but there were a couple things noted along the way I thought I’d share.

Start off by downloading the Ubuntu 20.04.6 AMD64 Desktop ISO. Yes, 20.04. Later installations aren’t supported by the REMnux installer.

Next you’ll want to burn the image to a flash drive, and make it bootable, using Rufus (Windows) or Balena Etcher (Mac.) This model MacBook has USB-A ports which seems like a relic compared to the current Macs. You’ll need at least an 8GB flash drive for the Ubuntu image. The first free one I could find was 32GB so I used that.

With the bootable USB drive inserted, power-up the MacBook and hold the option key until you see the different hard drives listed.

The flash drive is the one that shows as EFI Boot. Select it and hit return/enter.

Once everything is booted up you’ll get to the Try or Install Ubuntu menu. We’ll choose install.

Specify options as needed for timezone, keyboard, etc. For the username we’ll use remnux and the password malware as that’s the default. After the installation you can set the password for the remnux user as you wish.

At the Installation type we’ll choose Erase disk and install Ubuntu.

Sorry for the wavy resolution. Tough to get good screenshots during bare-metal OS installations.

Once the installation completes, hit Restart Now.

When I first logged in I was getting an error, “Activation of network connection failed” when trying to authenticate to the wireless network. Disabling IPv6 for that network fixed. it.

Now that we’ve got connectivity, we can grab any available Ubuntu updates.

sudo apt-get update && sudo apt-get upgrade

If at any point you’re prompted to do a distribution upgrade (a version of Ubuntu later than 20.04), choose Don’t Upgrade.

Once you’ve done all the OS updates, and rebooted, we can start the REMnux installation. We’ll be following the Install from Scratch instructions at remnux.org

wget https://REMnux.org/remnux-cli
sha256sum remnux-cli

Verify the hash matches the published hash 88cd35b7807fc66ee8b51ee08d0d2518b2329c471b034ee3201e004c655be8d6

mv remnux-cli remnux
chmod +x remnux
sudo mv remnux /usr/local/bin

The first time I ran the installer it failed as curl wasn’t installed. So take care of that before starting the install.

sudo apt-get install curl

At this point we’re ready to run the installation. The one deviation I’m choosing here is that rather than the standard install, I’m choosing the ‘cloud mode.’

If you’re depoying REMnux in a remote cloud environment and will need to keep the SSH daemon enabled for remotely accessing the system, use the following command instead to avoid disabling the SSH daemon. Remember to harden the system after it installs to avoid unauthorized logins.
remnux.org

In my case I plan to be ssh’ing into the box from within my own network more often than actual hands on keyboard, hence the cloud mode.

sudo remnux install --mode=cloud

At this point grab a coffee, walk the dog, or find something to do while the wall of text streams by.

Note if the install fails the first time don’t be afraid to re-run the install command a 2nd time.

Finally when it’s done, Reboot.

There you go. A shiny, happy, malware analysis machine.

Huntress CTF: Week 4 – Miscellaneous: MFAtigue

CTF, DFIR, Miscellaneous

MFAtigue

For any of these challenges where there’s a download and an online component, I’ll usually start with the files.

OK. So how can we get a password if we have access to the ntds.dit and the SYSTEM registry hive?

The iredteam.com article looks like a good place to start.

There’s a reference to dumping hashes using impacket.

I don’t have the SECURITY hive, but I do have the ntds.dit and the SYSTEM hive.

From here we’ll copy out all the hashes for user accounts. The accounts ending with $ are computer accounts so we won’t bother with those.

With the hashes isolated in a text file, we can run hashcat on the hashes using the rockyou wordlist.

…output continues…

We’ve got a match on the hash ending ..cadab42a.

Referencing that against our account information, we see that found hash is the password for JILLIAN_DOTSON.

Now for the url in the challenge. It brings us to a Microsoft sign-in page. We’ll use the account huntressctf\JILLIAN_DOTSON

And the cracked password of katlyn99…

Oh but wait. The account has MFA?!!

Hit the Send Push Notification

Then again,

And again…

After a mildly obnoxious number of repeated attempts….

Use the tag #HuntressCTF on BakerStreetForensics.com to see all related posts and solutions for the 2023 Huntress CTF.

Huntress CTF: Week 4 – Forensics: Bad Memory

CTF, DFIR, Forensics, Memory Analysis

Bad Memory

I spent a bit of time on this trying to get Volatility 2 to work with the Mimikatz plug-in. I was not successful. I was able to run the Volatility hashdump module.

I switched to Volatility3 and ran hashdump. For whatever reason the output of Volatility3 was different.

The only user besides the default accounts is for ‘Congo.’ Copy the hashed password and head over to https://hashes.com/en/decrypt/hash where we can search for the hash.

Yay, we got a match.

[Note: anecdotally I was advised that you could do this offline as well with Hashcat and the rockyou wordlist. I had tried that earlier but was using the Volatility2 output. 😦 ]

The last step is to convert ‘goldfish#’ to MD5.

Now just wrap it in the flag { } and you’re good to go.

Use the tag #HuntressCTF on BakerStreetForensics.com to see all related posts and solutions for the 2023 Huntress CTF.