I think I’m just a man with expensive hobbies because two years I ago I got really into skiing — finally cashing out on my own gear and a season pass — and this year I’ve decided to start homelabbing.

And no, I don't mean the type of homelabbing Walter White was doing, I mean more the kind that Lain does:

A homelab is a personal setup of computers and networking devices that are owned and operated entirely by yourself! They can be used to provide services or conveniences on your home network, such as: Network Attached Storage (NAS), a Network-wide Adblocker, personal Streaming Services, and much, much more. Basically like doing sysadmin work — not for a paycheck — but for the sole satisfaction of relying less on expensive cloud platforms and corporate-owned services and more on your own technical skills and hardware.

Why Build a NAS Server

There are many small projects you can build to start homelabbing, but a personal NAS server is one of the most common places to start. It's like having your very own Google Drive, one that you control entirely. The only storage limit you'll run into is governed by the hardware you have on hand. And the best part is that your files will no longer live in the "cloud" -- fancy term for someone else's computer -- they'll live on your drives and served by your server.

Hardware

First step of any homelab setup is hardware. No need to break the bank here, just start with whatever you’ve got laying around or source some for cheap (Dell Micro PCs are a great option).

I’m currently living in a place where my Dad used to live, and he left a 2010 Mac Pro 5,1 in the closet. It’s been collecting dust for years. I wanted to start my homelab with a smaller footprint and use something like a Dell Optiplex to run my NAS — but I don’t have one of those laying around — I have this huge cheese grater!

But don’t let its size fool you! Although this thing used to be a workhorse back in its day, it’s sporting:

• Intel Xeon W3520 8-core 2.793 GHz CPU

• AMD ATI Radeon HD 4870 GPU

• 8GB DDR3 RAM

This won't be enough compute to do as much as I want, but here's why I find it an enticing machine to start with (aside from the fact that I have it at my disposal).

Pros of the Mac Pro 5,1

• Modularity: These old Mac Pro towers are extremely modular. It was the last line of computers Apple built that were truly for the computer hobbyist. They are extremely easy to work on and upgrade (often times requiring no screws since things just slot into place), and they have 4 hard drive bays! That's pretty good for a starter NAS setup.

• Build Quality: It's Apple. Need I say more?

But of course, with a machine this old, it is not without it's drawbacks.

Cons of the Mac Pro 5,1

• Dated Hardware: This machine is old. Really old. It's also the single-processor model (dual-processor models offer more robust upgrade paths). I could upgrade the processor to something like a Xeon W3690 (a 6-core, 3.46 GHz chip) and up to 46GB RAM, but that's not in my current plans. Maybe someday.

• Power Draw: At idle this machine currently draws roughly 120-150W! That's a lot of power draw for something with such little compute! For reference, it's about 3x what a modern mini PC (like a Dell Optiplex) will draw. Here's some insane napkin math for ya (power is expensive where I live, roughly $0.45/kWh):

Assuming the machine is running 24/7:

That's insanely expensive for a homelab server! A more modern, power-efficient machine (like an Optiplex) would be way more cost effective (and powerful) in the long-term. But hey,

Quick Note: I didn't compute this until after I had already been tinkering with this machine for a bit. Oops. Don't make the same mistake as me! If you live somewhere with expensive electricity, be sure to consider power draw when picking out homelab hardware.

For the time being, and since I realized this so late in my journey, I will still setup a basic NAS server on this machine to get my feet wet. But I won't be running this thing 24/7. Once I pick up an Optiplex I'll take what I've learned here and migrate my NAS over to that machine. Maybe someday I'll upgrade this tower and use it for something else fun. I wonder if any of the upgrade paths available for this model could lessen the power draw?

Weighing the Pros and Cons

As it currently stands, this stock Mac Pro 5,1 is not in my long term plans for my homelab. It doesn't offer enough compute for how much it draws in power. However it can serve as a good starting machine to get my hands dirty. My current plan is to set it up as a NAS server so I can get familiar with administering tech like Samba shares or NFS. Once I pick up something like an Optiplex, or hell, even a Raspberry Pi, I'll migrate the server over to a new machine and decommission the tower — where it will return to collect dust once more. More seriously though, we'll likely keep it around as long as we have the space to store it. If I find myself with money burning a hole in my pocket, it would sure be fun to substantially upgrade it.

Schrödinger’s Important Data and the Mac Tower Debacle

Thus, my journey to build the MacNAS began ... with a rough start. The system booted up okay, but wouldn’t successfully log in to any user accounts. It would simply load and load and keep on loading, never dropping me into a desktop environment. I wanted the satisfaction of interacting with an ancient OSX desktop, and opening the “About” page to see the system’s specs. More importantly though, my first mission was to ensure no important data still resided on the machine’s internal HDD. When my dad was using this, he was working on movies he made with his best friend. I wouldn't want to jeopardize losing those files. He left behind two external HDDs, which I was pretty certain contained all his important data, but I wasn’t willing to risk it by wiping the internals until I double-checked myself (I couldn’t reach him at the time bc it was late though I shot him a message).

I followed a few common troubleshooting steps — booting into safe mode, various options in recovery mode, disk-repair, resetting NVRAM/PRAM, single-user mode, and even tried reinstalling the OS — none of that worked. I was fairly certain that the operating system had been corrupted beyond self-repair after running various commands in the terminal resulted in “cannot find this library”-type errors. On the other hand I was confident that the drive was still functional, not only because the disk-repair output seemed fine, but also because it wasn’t making any obvious noises that would point to HDD failure.

After torturing myself with this for far too long I realized I was being silly. I could just flash a live Ubuntu image onto a flash drive and boot into it on the tower, then mount the drive into my live Ubuntu environment. That way, I could explore the contents of the drive before performing a full-wipe.

After flashing the live Ubuntu image took nearly 20 minutes (it's a 6GB ISO), I decided to call it a night. In the morning I woke up to a text from my dad. He confirmed my suspicion that the OS install on the internal drive was corrupted, his OS was installed on one of the two external HDDs. He also told me that he has backups of all important files that he yanked off the externals a while ago, so I was clear to wipe everything.

But ... I realized there was another movie project he worked on. A documentary about my grandfather, for his 70th birthday. I asked him once more if that was included in his backups he has on hand. He wasn't sure. So I had to check the contents of all the drives I had before wiping anything. I was back to my original plan: I booted into the live Ubuntu environment the next morning.

Inspecting the Drives

Within the Ubuntu live environment there are a few things we need to do in order to inspect the contents of the internal HDD and the external HDDs. For now, I can only connect one external HDD at a time (starting with the G-Drive), since I only have one FireWire800 cable. Additionally, I have no idea where the power cable for the WD drive is, so that will have to come later. We'll set aside the WD drive for now and only focus on the 4TB external and the corrupted internal.

First thing I like to do when preparing to mount drives is to run lsblk to see what I'm working with and how the drives are laid out:

ubuntu@ubuntu:~$ lsblk
#------------------------------------------
sda     8:0    0  596.2G 0 disk     # <-- This is the Internal Drive
├─sda1  8:1    0  200M   0 part 
├─sda2  8:2    0  595.4G 0 part
├─sda3  8:3    0  619.9M 0 part

sdb     8:16   0  3.6T   0 disk     # <-- This is the External Drive
├─sdb1  8:17   0  200M   0 part
├─sdb2  8:18   0  3.6T   0 part
├─sdb3  8:18   0  619.9M 0 part

sdc     8:32   1  14.9G  0 disk     # <-- This is the Live USB
├─sdc1  8:17   1  5.9G   0 part /cdrom
├─sdc2  8:18   1  5M     0 part
├─sdc3  8:18   1  300K   0 part
├─sdc4  8:18   1  9G     0 part /var/crash
#------------------------------------------

This tells me the internal drive is /dev/sda (I know it's the ~600GB drive), the external drive is /dev/sdb (I know it's ~3.6TB), and the live USB I'm booted into is /dev/sdc (mounted at /cdrom). Next I can mount both the internal and external drives to inspect their contents, noting which partitions I need to mount (the root partitions) -- these are /dev/sda2 and /dev/sdb2 respectively. I create mount points for each drive and mount them:

sudo mkdir /mnt/{internal,external}
sudo mount /dev/sda2 /mnt/internal
sudo mount /dev/sdb2 /mnt/external

Then, in the Ubuntu file explorer, I can manually navigate to /mnt/external and /mnt/internal to inspect the contents of each drive. Going through /mnt/external I was quickly able to find the documentary about my grandfather! I also found other photos and stuff that seemed important to my dad.

Backing Up Important Data

There was a few ways I could go about backing up the data. I could:

1. Buy a large enough external HDD to copy all the important files onto. (Cost: ~$100+)

2. Buy one USB-B to USB-C cable, one USB-3.0 to USB-C cable, and one SATA to USB-C cable, then connect both externals and the internal to my laptop and copy the files over that way. (Cost: ~$60)

3. Connect the Mac tower to my home network via Ethernet (already done), expose an SSH server on the live Ubuntu environment, and then copy the files over the network to my laptop. (Cost: $0) 🎉

Tip: Always Consider All Possible Paths!

When trying to solve a problem, it's always good to brainstorm all possible solutions before committing to one. This way you can weigh the pros and cons of each method and pick the one that best suits your needs. In this case, it's pretty clear that option 3 is the way to go. You don't have to go buy anything when good ol' SSH and SCP can get the job done. It's the most elegant solution by far.

Exposing SSH on the Live Ubuntu Environment

First step is to install and start the SSH server:

sudo apt install openssh-server
sudo systemctl start ssh

# we set a password for the `ubuntu` user so we can log in remotely 
sudo passwd ubuntu # live sessions have no password by default

Now before we connect from our laptop we need to know the IP address of the Mac tower. Thus we run:

ifconfig # Make note of the Mac Tower's private IP address

Copying Files Over SCP

Now that we have an SSH server running on the Mac tower, and we know its IP address, we can use scp from our laptop to remotely copy the important files over the network.

scp -r ubuntu@<ubuntu-local-ip>:/mnt/external/path/to/files \ 
                                /path/to/local/destination

Until Next Time

Oh something I forgot to mention is that my main display (and only in-use monitor at the moment) is a 3440x1440 ultrawide. The Mac does not like this. My guess is due to how old the GPU/GPU firmware is, but it caused a lot of annoyance when the picture would render halfway off the screen and I couldn't see what I was doing. Even adjusting the aspect-ratio on my monitor from "Full-wide" to "Original" didn't help. If I was installing Arch I could blind-type my way through the install but I'm not familiar enough with Ubuntu to reliably do this. I unearthed an old Asus 24" monitor I used to game on and hooked it up. This worked much better, but I had removed the base of the monitor when transporting it and I have no idea where it ended up, so I have it propped up against the wall :P

Pretty janky, but it works. I'll only need it for a bit longer now. Now that I'm done copying the important files off the external drive, my next step is to wipe the internal and external drive, install Ubuntu, and setup the NAS functionality.

Once Ubuntu is installed, one of the first things I'll do is set up SSH so I can remote into it from my laptop and do all the setup/administration headless. But this'll have to wait until our next post. See you then!

As part of my 100 day Infosec challenge, I decided I would spend today diving deeper into DLLs, and learn about how they can be used to exploit Windows machines. Here are some of my key takeaways.

The Windows PE Format and Dynamic Linking

Before we can understand what DLL injection is and how it works, we need to know what a DLL is!

A DLL (Dynamic Link Library) is a Windows binary in the Portable Executable (PE) format. They are used to export code/data that can be imported by other programs at runtime. Every PE file contains several important components. We'll briefly go over only a few of them here:

• Import Address Table (IAT): Lists the functions that the DLL depends on from other DLLs. During the loading of these external DLLs, the Windows loader resolves the symbolic names and populates the IAT with function pointers. (Ref. https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#import-address-table)

• Export Table: Lists the functions that the DLL exposes to other programs; its public API. (Ref. https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#the-edata-section-image-only)

• DllMain: An optional entry point called by the loader during process/thread attach/detach events. It allows the DLL to execute initialization code. (Ref. https://learn.microsoft.com/en-us/windows/win32/dlls/dllmain)

The DLL Loading Process

For the sake of this article we’ll use the term “Windows Loader” to describe the cooperation between user-mode components (like ntdll.dll) and kernel-mode components (like the PE loader in ntoskrnl.exe) that make loading DLLs possible. So when we say “the loader” just know that it’s a system of multiple components working together, not a single program.

When a process needs a DLL, the Windows loader performs a carefully choreographed sequence:

1. Map the PE file from disk into the process's virtual address space.

2. Apply address relocations if needed.

3. Walk the import table and resolve all external function references.

4. Call DllMain with DLL_PROCESS_ATTACH to allow the DLL to initialize.

5. The DLL is now ready for use by the process.

Ref. Microsoft Docs Run-Time Dynamic Linking

What is DLL Injection?

The key idea behind DLL injection is to subvert or otherwise manipulate this loading sequence to execute arbitrary code inside the target process.

Classic Injection Method

The traditional approach to achieving DLL injection follows this pattern:

1. Get a handle to the target process (OpenProcess with appropriate privileges)

2. Allocate memory in the target’s address space (VirtualAllocEx)

3. Write the DLL path into that memory (WriteProcessMemory)

4. Create a remote thread that calls LoadLibrary on that path (CreateRemoteThread)

LoadLibrary does all the heavy lifting. The normal Windows loader takes over and performs all the steps we described earlier. The catch with this approach though is that it’s noisy. Modern Endpoint Detection and Response (EDR) solutions watch for exactly this pattern: OpenProcess → VirtualAllocEx → WriteProcessMemory → CreateRemoteThread.

Reflective/In-memory Injection

The weakness (e.g., the ease in which it can be detected) in the classic injection method above is due to the traces left behind by the loading process. In the classic injection method, the malicious DLL must exist as a file on disk and LoadLibrary must be called. This leaves behind two easily detected artifacts: (1) the DLL file itself and (2) The event logs associated with LoadLibrary invocations. Reflective injection, on the other hand, contains its own custom loader code, and only lives in-memory (not on disk). Hence reflective injection is harder to detect.

Because reflective DLLs bypass LoadLibrary, they must include a special function (the “reflective loader”) that manually implements everything the OS loader would normally do.

Aside: Meterpreter

The Meterpreter payload does all of this! First the initial stager (essentially a tiny piece of shellcode) establishes a reverse connection. This allows us to transfer the Meterpreter DLL over the network into target memory. The remaining shellcode stages allocate memory (VirtualAllocEx) and write the reflective DLL into a process's memory region (WriteProcessMemory). Execution is transferred to the reflective loader , which performs all the PE loading tasks manually. DllMain then executes, and Meterpreter establishes its full C2 channel.

In-memory injection makes incident response and forensics significantly harder. There’s no malicious binary to find on disk, no file creation events, and no LoadLibrary logs. Memory analysis requires knowing what to look for, so it is harder to detect, but by no means impossible (runtime/ memory artifacts are left behind).

Other DLL Attacks

I often get confused about related but distinct exploit techniques that are not considered injection attacks. I’ll attempt to make distinctions between them here.

Disk-based DLL loading, for example, involves placing a malicious DLL where a process will naturally load it. Two methods of doing this are:

• DLL search-order hijacking: Exploits the DLL search path when calling LoadLibrary to load a malicious DLL instead of the legitimate one

• DLL sideloading: placing a malicious DLL with the right name next to a legitimate executable that will load it. The following article goes more in-depth on this: Bitdefender - What is DLL Sideloading.

Process replacement techniques like process hollowing or process doppelgänging create what looks like a benign process but replace its code entirely. These are all related but distinct from DLL injection; the main distinction is that they’re not adding code to a running process.

Process Attacks vs. DLL Injection

They key difference between DLL injection and process doppelgänging, for example, is that DLL injection involves forcefully loading a malicious DLL into an already running legitimate process, while process doppelgänging involves creating a new, hidden, malicious process that masquerades as a legitimate one using file transactions.

Conclusion

DLL injection is a fundamental technique in offensive security. From dropping a Meterpreter shell in a CTF to advanced persistent threats, the ability to run code in another process’s context remains valuable across the threat spectrum. Reflective DLL injection specifically demonstrates how adversaries evolve techniques to evade detection -- by removing disk artifacts and implementing their own custom loaders, they operate in the gaps of traditional security mechanisms.

For security practitioners, understanding these techniques isn’t only about learning to attack systems, but about comprehending how modern malware operates so we can build better defenses, hunt more effectively, and respond to incidents with full knowledge of what adversaries are capable of.

References

Microsoft Docs PE Format

MITRE ATT&CK Process Injection: Dynamic-link Library Injection

red canary DLL Search Order Hijacking

OffSec About the Metasploit Meterpreter

MITRE ATT&CK Process Injection: Process Hollowing

MITRE ATT&CK Process Injection: Process Doppelgänging

Scott Nusbaum, TrustedSec Loading DLLS Reflections

https://forum.penumbra.zone/t/the-final-summoning-rites-part-2-mainnet-phase-0/32

What is Penumbra?

Penumbra is a shielded, cross-chain network allowing anyone to securely transact, stake, swap, or marketmake without broadcasting their personal information to the world.

At its core, Penumbra is a privacy-preserving CometBFT Proof-of-Stake (PoS) blockchain. It boasts several standout features, including a native decentralized exchange (DEX), interop with IBC, private staking and governance, and ultralight client software.

Home is Where the Shielded Pool is

Penumbra is natively cross-chain (IBC-enabled), making it akin to an ecosystem-wide shielded pool for the entire Cosmos and beyond. Inbound IBC transfers shield value as it moves into the zone, while outbound IBC transfers unshield value.

One of the most challenging aspects of designing a private blockchain is in reconciling the tension of simultaneously desiring individual privacy and network transparency. To address this tension, Penumbra records asset flow in batches utilizing a partially homomorphic encryption scheme coupled with Distributed Key Generation (DKG). Validators each hold a key-share, enabling them to perform threshold decryption of batch totals every block. Individual transactions are kept private using Groth16 proofs of valid state transitions, ensuring that every move you make remains your own.

https://penumbra.zone/blog/how-were-building-penumbra

Penumbra boasts the world’s first shielded PoS network, through the use of a novel delegation mechanism, Penumbra provides privacy for delegators and accountability for validators. Each validator has their own unique delegation token (dPEN), which represents a share of the delegation pool staked with that validator. These tokens are recorded in the shielded pool and can be transferred or traded like any other asset. Users can privately delegate to a validator by exchanging staking tokens for the validator’s delegation token. Rewards are issued to the delegation pool and are realized only when a delegator withdraws their delegation.

https://penumbra.zone/blog/shielded-staking-on-penumbra

Network Bootstrapping

The Penumbra Labs team has not launched any public GRPC endpoints of their own. The network is in a bottom up bootstrapping phase spearheaded by the community. Community members have begun spinning up their nodes and sharing publicly accessible endpoints for use in client software (Prax, pcli).

https://x.com/penumbrazone/status/1810055221659504897

To access the embedded frontend of a full-node’s endpoint, simply append /app/ to the node’s url. Example: https://penumbra.phasewalk.software/app/.

GRPC Endpoints

• https://void.s9.gay

• https://penumbra.phasewalk.software

• https://grpc.penumbra.silentvalidator.com

• https://grpc-penumbra.whispernode.com

A longer list of endpoints can be found in the community-rpc channel in the discord.

Where Can I Get Involved?

Penumbra is decentralized and owned by no single entity, inviting participation from developers, researchers, node operators, and users who are passionate about privacy and decentralization. Here are some ways to get involved:

• Forum: Join the discussion on the final summoning rites and stay updated on the latest developments at https://forum.penumbra.zone

• Guide: Learn how to use the Penumbra software to interact with the network or run a node at https://guide.penumbra.zone

• Spec: Dive into the technical details with the protocol specification at https://protocol.penumbra.zone

• Code: Contribute to the project or explore the codebases at https://github.com/penumbra-zone

As we move forward, Penumbra stands as a beacon for the future of self-sovereignty, coordination, and freedom. Go forth and complete the final summoning rites. Where bits find darkness, in the Sun’s shadow.