It has been almost five years since I last posted anything here. My last post was in November 2021, and looking back now, that feels like a completely different point in my life.
At the time, I was working as an Application Analyst. In 2022, I moved into an AWS Ecosystem Team Lead role, and by 2025 I had moved into my current position as an Infrastructure as Code Technical Manager and SME. My work has changed quite a bit along the way. I went from application support, to cloud infrastructure, to spending most of my time around automation, standards, architecture, and technical leadership.
A lot changed outside of work too. My son was born in January 2020, I got my EMT certification in August of that year, and I spent some time with the local rescue squad.
In 2022, I got married, and a seven-year custody dispute finally came to an end with true 50/50 physical custody.
My daughter was born in March 2023. That same year, I was given school placement. In July, I completed the last nighttime police academy offered at the local community college, and a few months later, in October, I joined the local fire department.
I started the nighttime fire academy in January 2024. It took a little over a year to finish, and in February 2025 I became a certified firefighter.
Then February 2026 happened.
While operating at a brush fire, I had a heart attack and went into cardiac arrest. I received CPR, was shocked multiple times with an AED, and was taken to the hospital where a completely blocked LAD was opened and stented. That turned into an ICU stay, kidney failure, dialysis, and several months away from the fire department while I recovered.
That was not on the schedule.
Thankfully, I recovered well enough to eventually return to full firefighting duties.
While all of that was happening, the home lab also changed quite a bit.
This was my network in 2021:
Home network, 2021
At the time, the setup centered around an EdgeRouter X, XenServer, a Debian PC acting as a network tap, a FreeBSD VM, VLANs, and a dedicated malware analysis network. It was already much more complicated than a normal home network, but compared to what it looks like now, it was fairly simple.
This is the network today:
Home network, 2026
There are now two separate Internet connections. The normal home network uses 2 Gbps fiber, while the lab has its own 1 Gbps coax connection. The lab side now includes OPNsense, Proxmox, multiple management and data VLANs, Windows Server, dedicated Logstash systems, a Debian network tap, Cisco switching, and several separate management networks.
The home network has expanded too, with dedicated wireless networks, an isolated IoT network, a separate VR network, WireGuard connectivity, and a 10 Gbps connection to my main desktop.
Looking back at the 2021 diagram, I remember thinking that setup was pretty elaborate.
Apparently, Linux’s favorite file sharing service can also double as an Active Directory Domain Controller. I’ve taken two Linux classes and was even a Linux Administrator for many months, and I had no idea this was possible. I stumbled upon this fact because I am looking for a centralized way to manage my user accounts across my entire home lab network.
Since I am using my free AWS Windows server for this site, I had no choice but to find an LDAP server implementation on Linux since AWS gives you a free Windows and Linux server. I spent a good bit of time looking at OpenLDAP, but that will not work since Windows cannot join an OpenLDAP domain. So back to the drawing board I go. I briefly looked at pGINA, but that looks like it hasn’t been updated in almost a decade. Finally, I stumble upon……
Samba.
What? Isn’t that just a file-sharing service???
Apparently not.
Part 1: Pre-Installation
I fire up a RHEL instance within AWS’s EC2, and I get port 389 configured from Windows <-> Linux. I then follow the pre-install instructions on Samba’s site. To set up EPEL on AWS’s RHEL, you need to run the following commands:
I have added flex, Bison, dbus-devel, and python3-markdown because Samba’s configure command requires them. We will get to this in a moment.
Now we will need to set a hostname and change our /etc/hosts file. First, to change your hostname, run:
sudo hostnamectl set-hostname yourhostname
Next, get your IP address using:
ip addr show
Then add your hostname and IP address to /etc/hosts using:
sudo vi /etc/hosts
Press the “i” key to enter Insert mode, then use your arrow keys to navigate to the end of the file. Press enter, and add your IP address and new hostname like so:
Your hosts file may make the localhost lines different.
Finally, exit insert mode with Ctrl+C, then type Shift+; (to enter : ), press x, and hit enter. This will save your new hosts change. After making your change, log out and log back in.
Part 2: The Install
If you look on the Distribution-specific Package Installation page, it explicitly states that installing Samba from the repository does not support Active Directory. We can either jettison this RHEL install and move everything to Ubuntu or build from source. Building any software from source is always a challenge, and well, that’s why we’re both here!
First, grab the most up-to-date tar.gz installation files (the most up-to-date version as of this writing is 4.15.2). In my case, it will be:
wget https://download.samba.org/pub/samba/stable/samba-4.15.2.tar.gz && tar -zxf samba-4.15.2.tar.gz && cd samba-4.15.2 && ./configure
The following command with download the tar.gz file, extract its contents, change the directory to the newly extracted folder, and run the ./configure command. For our purpose, we can leave the default configuration options alone. Once the configure command completes, you should get the following:
Success!
Next, run the make command. This will take some time. Once make finishes, you will see:
Another success!
Finally, run the sudo make install command. This will also take some time. Once the install finishes, you will see:
Final success!
Next up is creating the systemd file used to start and stop the Samba Active Directory Domain Controller automatically. Enter the following:
sudo vi /etc/systemd/system/samba-ad-dc.service
Like before, press “i” to enter insert mode, copy and paste the following:
Ctrl+C, then type Shift+; (to enter : ), press x, and hit enter. If you try to start Samba now using systemctl start samba-ad-dc, it will fail with the following:
SELinux prevented Samba from running.
Before starting Samba, SELinux will need to be adjusted to allow Samba to run. Run the following command:
chcon -R -t bin_t /usr/local/samba/sbin/
The above command will tell SELinux that Samba is permitted.
Part 3: Post-Install Configuration
Before Samba can be started, we will need to configure it. Begin by running the following commands:
This will tell samba-tool to provision a domain using the interactive tool and allow RFC-2307. Without RFC-2307, non-Windows clients would be unable to authenticate with this server. The interactive tool will ask many questions, but you only need to provide the Realm (internal.domain.com) and the administrator password. THE ADMINISTRATOR PASSWORD MUST BE SECURE. The other settings can be left as default. Once you see the following, the tool is complete:
INFO: Samba-Tool is complete.
The last thing that is needed is the following command:
This command will move the Kerberos configuration file to the correct location, request systemctl to start samba-ad-dc, and output its status. If everything was completed successfully, you should see:
Perfection.
Part 4: Next Steps
Now that Samba’s Active Directory Domain Controller is running, we will need to test our configuration. If the tests are successful, we will need to deploy it to the other clients. That’s Part 2!
Last week I had to attend my grandfather’s funeral. He was 72 years old and in feeble health when he passed, so he is in a better place now. However, I had the chance to finally clean my storage unit out that I’ve had since 2018! It was a 5’x10′ unit, and the entire contents of the unit was dumped into my house. I finally got a chance to unpack, and I set up my new bookshelf and added new items to my home lab.
Introducing my new home lab!
My home lab
The two major additions are the Commodore 64 plus a disk drive and the TI-99A. I have big plans for the C64, so stay tuned! From bottom to top: HP ProLiant ML350p Gen8, Edgewave iPrism 75g, Dell Poweredge R310, Cisco Catalyst Express 500, a Debian PC used as a network tap, a Windows PC where the motherboard failed, two legacy Windows 98 PCs, a Commodore 64, a TI-99A, and three VGA/DVI monitors
Next up is my bookshelf. Some of these books I already had, but the majority of them came from my storage unit.
Full bookshelfZoomed to the IT books
These past few weeks have been wild. Beginning in the first week of June, I started a summer research position at North Carolina A&T’s autonomous robotics lab. I had to contribute 160 hours in the lab for the eight-week summer semester. Along with that, I worked full time while pursuing 12 credit hours at the local community college. I am SO glad that it’s over. I can finally get to my home lab projects and then begin a few others. I need to upgrade my uploader service and fully release it. After that, I will do some malware analysis within my analysis lab. Finally, I will sit down and write Part II to the mainframe series.
The only way one can gain legitimate access to a mainframe is by either shelling out five figures or more a year or getting a job supporting a mainframe. Since mainframes are used in 71% of all Fortune 500 companies, it’s not like you have slim pickings to snag a job.
But what if you already have a job and you don’t want to leave?
If you want to be legitimate, you must pay or get a new job.
Surely there must be a way.
Of course there is! It’s 2021 of course. And now your here. You really want to run your own mainframe from the comfort of your home. Sadly, you will have to wait for Part #2.
This post is about the pre-setup for getting a bootleg mainframe running in my home. I will discuss what I’ve been up to in my lab the past couple of days.
Puppy Linux is one of the most lightweight Linux distros there is. XenServer can pull ISOs from an NFS or Samba share, so I shared a folder from my Windows PC and set XenServer to boot from the ISO image there. After I installed Puppy Linux, I can freely install VMs from the server.
My current ISO library
As you can see in the picture, my first VM installed this way is Lubuntu. It’s another lightweight Linux distro that will run the z/OS (mainframe) emulator. I have *ahem* acquired a copy of z/OS 1.10 that is floating around the internet. I will then run the mainframe emulator called z/OS Hercules. That will be covered in part 2!
After several weeks and a trip to Goodwill, I have successfully implemented my malware analysis lab as envisioned!
Part I: The Setup
My network is as follows:
Network Diagram
I have the Edgerouter X serving several VLANs, but there are two in particular that I will discuss today. The two ethernet ports on the XenServer serve two purposes: one ethernet port connects to the VLAN aware switch and provides management functions, and the other is used by the VMs for a network connection. This network connection is connected to a Debian PC with two ethernet ports bridged together. That way I can snoop on any network activity silently to the VM. I can also break
Along with this upgraded network, I have revamped all of my firewall settings:
Firewall settings
In this, let’s look at VLAN400 (my PC and its VMs), VLAN325 (XenServer MGMT), and ETH1 (both IN and LOCAL). ETH1 has the largest group of firewall policies (11 in total) than any other network. For IN, it can not communicate with any of the VLANs except for the FreeBSD VM located at 192.168.40.100, but only if it originates on the Debian PC. This way, I can have a full two full virtual layers of protection between this network and the rest of the network. If malware were to escape to my main PC, its chain of infection would be either:
Infected VM -> XenServer itself -> FreeBSD VM -> PC
Or
Infected VM -> Debian PC -> FreeBSD VM -> PC
ETH1-IN Firewall Rules
For ETH1 LOCAL, it has two simple rules: Allow port 53 to the router, and deny everything else. This way, any VMs are unable to attack the switch itself through any of the VLAN IPs.
ETH1-LOCAL firewall rules
VLAN325 (the XenServer MGMT VLAN) has a similar firewall policy. It can only communicate with the FreeBSD VM:
All of this configuration is well and good, but does it work? All the configuration in the world does you no good if it simply doesn’t work in the first place!
Part II: Testing the configuration
Can my PC ping the Debian PC or the XenServer IP in the 10 network?
No.
Can my PC ping the XenServer MGMT IP?
Also nope.
Can the XenVM ping the PC?
Again, nope
Can it ping the 10 network’s switch IP?
Nope!
With our simple ping test, we can conclude that the firewall rules are working as expected. To confirm, I did do an NMAP scan of 192.168.40.* with the following commands: nmap -T4 -d -v -F -Pn 192.168.40.1 192.168.40.2 192.168.40.10 192.168.40.100
Sure enough, not a single packet returned!
NMAP scan from XenVM
However, the 10 network isn’t so lucky. The switch gateway has DNS open; the Debian PC has ports 7, 9, 13, 21, 22, 25, 37, 53, 79, 80, 110, 113, 990, 995, and 3389 open; and the XenServer has ports 22, 80, and 443 open. I’m sure the iptables firewall could close the XenServer ports, but the open ports on the Debian PC are due to two programs I’ve installed.
My first foray into serious malware analysis was in 2019. I was running a Windows VM within VMWare with an active internet connection and shared folders enabled. Fast forward a year and four months later, I have dedicated equipment and a very mature network and firewall setup. I think it has come time to do actual research on my setup and see just how well it can perform. As far as any upgrades to the existing setup, I would like to move the FreeBSD VM to its own PC altogether. After that, I would like to fully physically segment my lab network from everything else. Even up to the point of having its own router!
A couple of weeks ago I wrote a one-page paper for a college class that I am about the Clop ransomware. Tonight, I decided to install Tor and try to locate Clop’s leaking site. That was actually very simple as a kind Redditor published a list of the well-known ransomware operators and their PR page. Sadly, since these are onion sites, you need the Tor browser to get to the page. I have never used Tor or installed it in my 27 years of existence.
Until today! And what’s the first onion site I go to?
In my last post, I wrote about how I wanted to be a webpage that will allow me to upload files to my server so I can store them for later analysis. Well, Microsoft has graciously written an ASP.NET Core program that does just that! That way, I don’t have to build the entire thing from scratch!
After working on it for about 20 or so minutes, here’s what I have:
Puter Services Malware Upload Center
My idea for this is twofold:
A central storage for malware I find while away from home
The ability to submit the uploaded files automatically to VirusTotal, Hybrid-Analysis, and AppAnyRun so that I don’t have to manually.
After it submits, it will then automatically download the completed report so I can view it later. Finally, it will also send me an email with the results. This way I don’t have to manually upload, keep malicious files on my phone/computer, or keep refreshing a page until I get the results.
This should be completed by the end of this weekend. I plan on livestreaming next time I work on this!
During the last post, I got to adding a separate network for the malware analysis server to sit on. When I clicked on save and update, the router refused to work correctly. Sadly, I could not get it to stop boot looping or keep the router powered on. After that, I reverted my changes, bought a new router, and prayed that it stayed healthy long enough to switch to the new router.
My new router
I decided on a Ubiquiti EdgeRouter X. Small form factor, able to deliver gigabit speeds, and packed with all the settings I am accustomed to having. I got it plugged in, configured, and tried to change my wireless router to a switch. It totally failed at that point. I then had to buy a new wireless access point.
My new Wireless Access Point
I ended up deciding on a Ubuquiti Unifi AP-AC Lite for my access point needs. It too has the features I am accustomed to having. It made for a simple setup that was painless and user friendly.
Finally, my last goal was to enable VLAN tagging on the AP and the router. After 15 factory resets, I now have VLANs enabled on the router. Woo!
VLAN Setup
It definitely took a while to get everything configured, and I probably should have recorded the steps I took, but the information is out on the internet. Perhaps its a topic for a different day.
What’s Next?
The next pressing matter I have is I want to create a program where I can upload malicious files for later analysis. After that, then I can finish setting up the analysis lab and do the analysis on the Clop sample I located.
Following these directions, I was able to successfully install OpenVM Tools within my FreeBSD environment. It took a couple reboots, but everything worked as expected. It was nice to finally have something work on the first couple tries!
Part VII: Installing Xen Orchestra
This one was pretty easy. Xen Orchestra requires 4GBs of RAM, and a few dependencies specific to FreeBSD. These are:
After everything is installed, you can then follow the official documentation. Once built, configured, logged in, and attached to your XenServer, it will look like this:
FreeBSD running Xen Orchestra
Part VIII: Implement Firewall Rules
Out of everything in the lab, this is the absolute most important. Without adequate firewall rules, the Windows 7 VM can interact with anything on the network. This is… not good. Especially considering most malware nowadays can spread at the speed of light. So, we will need to implement rules in order to protect everything on the network. Currently, my router acts as my firewall, so we will configure it from there.
The first part is to connect the XenServer to an open port, and assign a new VLAN to it. For my setup, the server is connected to port 3 and I have assigned it VLAN 12:
Buffalo DD-WRT VLAN Page
This will reboot the router, and once the router comes back up, port 3 no longer has access to the network. We can identify this from our previously connected XenCenter reports the XenServer offline:
RIP to XenCenter. It was good while it lasted
Now its time to configure our VLAN. I labeled it “To MAL”, enabled NAT masquerade, net isolation, and assigned an IP address of 10.10.220.1. The DHCP server is set to start at .35 and have a maximum of 5 IPs:
vlan10 & DHCPd configuration
Finally, I have to write the firewall rules, which will have to come later. Until next time!
In order to more safely analyze malware, I needed an entirely separate environment to run harmful programs. Previously, I would run them in a VM hosted on my personal computer through VMWare. This is how the VBScript was de-obfuscated.
That’s why it’s in its own VM. To ensure that should it break, it won’t destroy the rest of the computer. Unless it escapes of course.
“Escape? Escape from what?”
There are certain exploits that malware can use to “break” out of its sandbox, and thus run whatever hack code they want on your own computer.
“Perhaps it is not the best idea to run malware on your own computer.”
And that is why I have revamped my malware analysis lab! I will be running malware on a VM hosted on a Dell PowerEdge R310 with Citrix XenServer. I will have a firewall rule in place to only allow the XenServer to communicate with the outside world and a FreeBSD VM running on my computer. With XenServer, I can run a program called Xen Orchestra in order to manage my XenServer. That way, my personal computer should be much more protected in case of malware attempting to break out. The workflow would be as follows:
Personal Computer -> FreeBSD VM -> HTTPS -> XenServer -> Malware VM
I have 90% of this setup up and running right now. Here is what I did:
Part I: Deploy New Webserver
The first thing I needed to tackle was to set up a new server for my website and this blog. I chose AWS because a simple Windows Server would cost me about <$20/month whereas GCP and Azure would have costed a bit more. Simple enough. AWS EC2 makes it simple and quick to launch new instances for whichever need you have. I chose Windows because I wanted to have the experience of being my own Windows Server Administrator.
This would prove a disaster later on.
I get my Windows Server set up, install IIS and the required plugins, set up my server, and figure out how to install WordPress. Web Platform Installer has an automatic WordPress install. Woo!
Web Platform Installer showing WordPress
Installed it, got it configured, and…. there’s a security warning. Apparently this version of WordPress installs PHP 5.1 !!!, MySql 5.1!, and an outdated WordPress version. These are horribly out of date. Need to update.
First on the list is WordPress itself. It has a button. You click the button and boom. Updated 🙂 Easy enough.
Second is PHP. Got PHP 7.4 installed, and now WordPress has an error. I ran PHP manually from the command line, and I get an error popup:
PHP error popup. PHP 7.4 has a dependency.
A quick Google search states this is due to PHP requiring the Microsoft Visual C++ Redistributable for Visual Studio 2019. I installed it, WordPress no longer has an error AND reports that PHP is up to date.
Next was MySql. That was rough. It took me 4 days, and I ended up deleting everything, including the Windows Server itself, and started over from scratch. This time, I installed everything manually, using the official installation walkthrough. After that, worked like a charm.
Part II: Securing the WebServer
This is the next thing that took forever at two days. I originally went with OpenVAS. However, I quickly found out that OpenVAS is now Greenbone Vulnerability Manager. It is the absolute worst thing I have ever had the misfortune of attempting to install. Since it is a Linux application, I had to fire up a Linux VM. My first try was in Ubuntu, however, the apt-get didn’t work. It just simply didn’t start at all. My second through sixth attempt was in Kali Linux. All attempts failed. I used apt-get, an automated script I found on GitHub, the manual build process, and a mix of both. It just simply didn’t work. Fine. I then tried to use their pre-packaged VM. But that too failed. I gave up on GVM.
So I then went to my good friend Nessus. I installed it in my Kali VM, and it worked the first try. As of this writing, I have 9 medium vulnerabilities to fix:
8 Medium vulnerabilities, 42 info
The last thing I needed to do was run the Microsoft Baseline Security Analyzer. However, that is no longer supported 🙁
🙁
I did find out that its successor is the Microsoft Security Compliance Toolkit. So, I have something else to get running.
Part III: Building the Malware Analysis Environment
Out of everything, this was the easiest. I was originally going to go with VMware’s ESXi, but my PowerEdge is too out of date. However, Citrix’s XenServer happily runs on the old hardware. Tough decision that was 🙂
Since I do not have a DVD drive, I have to boot my new OSs through PXE Boot. I use (and highly recommend) Serva for all my PXE Boot needs. Simple to install and works without a hitch. I got XenServer installed, and then XenOrchestra installed on my Ubuntu VM for testing. It works! However, it appears I couldn’t start VMs through XenOrchestra, so I installed XenCenter. Worked perfectly. Well… almost.
I configured my Windows 7 VM on XenServer, got Serva running, tested Serva on my PXEBoot VM, and went to install Win7. Nope. Connection timed out. No matter which settings I tried, the guest VM refused to boot. I even tried another PXE Boot server. Didn’t work. Was my project dead in the water? It almost was until…
I realized I can IMPORT VMS through XenCenter!
gasp
And VMware Workstation can export! I can load VMs this way!
gasp… it will work!
So, Windows 7 was installed in VMware, exported, imported into XenServer, and now it runs!
XenCenter with VM running in XenServer
Part IV: Installing FreeBSD
This was the most difficult part of this project. I have never used FreeBSD in my lifetime. Never even seen it. FreeBSD installed fine, but it doesn’t come with a GUI. So I installed the GUI, set the resolution, and it appears to be working. Sweet. I just have to finish configuring it for VMWare, and then I can install Xen Orchestra.
FreeBSD
Part V: Finding Malware
I have decided my first analysis will be on the Clop Ransomware. This is a really nasty piece of malware family that encrypts your files until you pay. I wrote a paper on the Clop ransomware, so naturally, this would be the first analysis done. My first step is to actually find it in the first place. The McAfee blog gave me an MD5 hash of:
ed7db8c2256b2d5f36b3d9c349a6ed0b
So we have our starting point. The first place I searched from this list is app.any.run. So I put the MD5 has into the search and…. could it be?
App.any.run results
On the first try, no less! There it is! In all its glory! Or is it? There’s only one way to find out.
The McAfee blog post shows a snippet of the disassembled code with the memory address included. If we go to that specific memory address, we find….
Disassembly of captured sample vs McAfee’s blog
The same. exact. assembly code in McAfee blog post. I can conclude with reasonable accuracy that I have acquired the Clop ransomware file. Next week, I will dive into this sample!