September 13, 2026 • 19 mins
This episode establishes the essential development foundations across Windows and Linux, preparing the workspace for advanced scripting, application development, and future security-focused projects.The episode takes a practical, hands-on approach, configuring a Windows development environment and then building a complete local web and database stack on Ubuntu.1. Configuring the Windows Development EnvironmentThe first part of the episode focuses on preparing Windows for C# and .NET development.The setup includes:
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cybercode_academy
- Installing .NET Core
- Installing Visual Studio Code (VS Code)
- Installing the C# extension for VS Code
- Creating a dedicated project directory named "Red team develop"
- Initializing a new console application
- Using the integrated VS Code terminal
- Compiling and running a simple "Hello World" application
- Verifying that the complete development toolchain is functioning correctly
- Apache — Web server
- MySQL — Database server
- PHP 7.2 — Server-side programming environment
- PHP database extensions
- PHP multibyte string extensions
- Atom — Code editor
- Checking the Apache service
- Checking the MySQL service
- Confirming that services are running in the background
- Troubleshooting installation or service-related issues
- Ensuring that the local development stack is ready for application development
- .NET Core
- Visual Studio Code
- C# development support
- Dedicated application project directory
- Verified console application
- Apache web server
- MySQL database server
- PHP
- Required PHP extensions
- Atom code editor
- Verified background services
- Set up a functional C#/.NET development environment
- Create and execute a basic console application using VS Code
- Install development packages on Ubuntu
- Configure an Apache + MySQL + PHP stack
- Verify Linux services and their background operation
- Install and configure a Linux-based code editor
- Prepare a cross-platform workspace for future development and security exercises
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cybercode_academy
Listen
Watch
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
So if you want to catch a hacker, you don't
just set a trap. You kind of have to build
the exact hands they're going to break into.
Speaker 2 (00:05):
Right, yeah. And you have to literally forge the tools
to pick your own locks.
Speaker 1 (00:09):
Exactly. I mean, you have to understand the metology of
the lock, the tension of the springs, all the vulnerabilities
of the architecture before you can ever really hope to
secure it.
Speaker 2 (00:18):
Oh, absolutely.
Speaker 1 (00:19):
So today, we are analyzing a set of foundational technical blueprints.
And our mission for you, the listener... is to explore
how to actually construct both the locks and the lockpicks
from scratch. We're doing a deep dive into building a
dual environment development laboratory.
Speaker 2 (00:37):
Which is such a critical exercise for anyone who's, you know,
serious about technology.
Speaker 1 (00:41):
Yeah. So first, we'll construct a specialized Windows environment for
writing compiled software. And then we're going to pivot entirely
and configure a Linux Ubuntu system designed specifically to host
dynamic web services.
Speaker 2 (00:55):
Because, I mean, the environments we are about to break down,
they're not just simulations. These are the exact frameworks enterprise
developers use to build applications. And simultaneously, they're the exact
staging grounds cybersecurity professionals use to tear those same applications apart.
Speaker 1 (01:10):
Wow. So by building these two distinct nodes, you're essentially
creating a localized microcosm of the Internet itself.
Speaker 2 (01:18):
You really are, yeah.
Speaker 1 (01:19):
Okay, let's unpack this. Let's step into the first part
of this laboratory, the Windows Workspace. This is essentially our
application workbench.
Speaker 2 (01:26):
Right. The foundation.
Speaker 1 (01:27):
Yeah. So the blueprints initiate the process by having us
navigate to google.com, search for. NET Core, and head straight
to the official net.microsoft.com domain. But there's the detail here
that immediately jumped out at me.
Speaker 2 (01:42):
Oh, the 32-bit thing?
Speaker 1 (01:43):
Yes. The instructions explicitly specify downloading the 32-bit installer for.
NET Core and running that executable. I'll admit, that just
stopped me in my tracks.
Speaker 2 (01:52):
I mean, I completely get why.
Speaker 1 (01:53):
Right. Because in a modern computing environment, almost everything we
touch is 64-bit architecture. So why are these blueprints pointing
us backward to a 32-bit runtime? Like, is there a
strategic reason for that, especially if we were setting this
up for security testing down the line?
Speaker 2 (02:10):
That is an incredibly sharp observation. And yeah, there's a
huge strategic reason. When you are building a lab for
offensive security, backwards compatibility is just paramount.
Speaker 1 (02:20):
Because of older systems.
Speaker 2 (02:22):
Exactly. A lot of legacy enterprise systems, the ones that
often harbor the most critical vulnerabilities, they still rely on
32-bit architectures.
Speaker 1 (02:31):
Oh, wow. Okay, that makes sense. Yeah.
Speaker 2 (02:33):
And furthermore, when you're first learning how memory works, you know,
how to manipulate pointers or execute a buffer overflow... A
32-bit memory address space is just significantly easier to map
out and understand than a 64-bit space.
Speaker 1 (02:49):
Oh, so it's practically a learning tool in itself.
Speaker 2 (02:51):
It really is. By forcing the environment into a 32-bit architecture,
the blueprints ensure that the payloads and tools you eventually
build will actually execute effectively against older, vulnerable targets without
some sort of architectural mismatch.
Speaker 1 (03:05):
I hadn't even considered the legacy aspect. You're essentially making
sure your digital lockpick gets into the older rusted locks
that organizations just forget to replace.
Speaker 2 (03:14):
That's a perfect way to put it.
Speaker 1 (03:15):
So, okay, we run the executable, the framework installs, and
the underlying concrete is poured. But a runtime environment doesn't
really help you write the code itself.
Speaker 2 (03:24):
No, not at all. You need a workbench. Right.
Speaker 1 (03:28):
The next progression in the blueprint is downloading Visual Studio Code.
And they make a specific point to mention that VS
Code is completely free, which is great. But as a
raw download, I mean, it's just a text editor.
Speaker 2 (03:41):
Yeah, it's essentially a blank slate at first. VS Code
is built on an extensible architecture. So out of the box,
it lacks the compilers, debuggers, the language-specific intelligence for heavy-duty development.
You have to mold it.
Speaker 1 (03:54):
And that molding process brings us to the next step.
Speaker 2 (03:56):
Yeah.
Speaker 1 (03:57):
So you open the app, navigate to the extensions menu.
And search for C Sharp. That's the letter C followed
by the pound sign. You install the very first extension
that pops up. But I do want to push back
on the language choice here. Okay.
Speaker 2 (04:08):
What are you thinking?
Speaker 1 (04:09):
Well, when I think of offensive security or, you know,
rapid application development, I usually think of Python for scripting
or maybe C + + for low-level memory access. Why
are the blueprints steering us towards C Sharp on a
Windows machine?
Speaker 2 (04:22):
I get that. But C Sharp actually provides a unique
tactical advantage in a Windows environment. Because Microsoft developed it,
C Sharp hooks natively and seamlessly right into the Windows API.
Speaker 1 (04:34):
Oh, the application programming interface.
Speaker 2 (04:36):
Right. So this allows developers or security testers to interact
directly with the operating system's core functions.
Speaker 1 (04:42):
Whereas Python wouldn't do that as easily.
Speaker 2 (04:44):
Well, if you write a tool in Python, it often
requires a heavy interpreter. and modern endpoint detection systems, they
can flag malicious Python scripts almost immediately. C Sharp, on
the other hand, it compiles into an intermediate language that
runs within the. NET framework. It just blends in. To
a security system, a well-written C Sharp executable often just
(05:06):
looks like normal enterprise software going about its day.
Speaker 1 (05:09):
Wow, so it's camouflage. You are building tools that speak
the native dialect of the target operating system.
Speaker 2 (05:16):
That's fascinating. And I guess that leads perfectly into the
naming convention the blueprints require next.
Speaker 1 (05:21):
Ah, yes, the folder name. Right.
Speaker 2 (05:24):
We are instructed to go to the desktop and create
a new project folder. But the instructions are really rigid here.
You must name this folder Red Team Develop.
Speaker 1 (05:34):
Yeah, they don't leave any room for interpretation there.
Speaker 2 (05:36):
They don't. They emphasize this folder will be the nucleus
for the rest of the curriculum. And I want to
unpack this term for the listener because Red Team... carries
a ton of weight in the industry.
Speaker 1 (05:47):
It really does. In cybersecurity, you basically have the blue team,
which defends the network, and the red team, which attacks it.
Speaker 2 (05:55):
Right.
Speaker 1 (05:55):
But red teaming isn't just, you know, randomly throwing exploits
at a firewall. It's a highly structured adversarial simulation. Red
teamers act as advanced persistent threats. They conduct reconnaissance, weaponize payloads,
and attempt to exploit vulnerabilities to achieve a specific objective.
Speaker 2 (06:12):
All without being detected. Right.
Speaker 1 (06:14):
All under the radar. So by naming this foundational workspace
Red Team Develop, the blueprints are really planting a flag
in the ground. We aren't setting up this C-sharp environment
to build some generic payroll app.
Speaker 2 (06:26):
No, not at all.
Speaker 1 (06:28):
We are staging the workbench to forge offensive capabilities.
Speaker 2 (06:32):
Precisely. You are building the armory.
Speaker 1 (06:35):
I love that. But an armory is pretty useless if
the forge doesn't actually fire up.
Speaker 2 (06:40):
Right.
Speaker 1 (06:40):
We have to verify that the. NET framework, VS Code,
and the C-sharp extension are actually talking to each other.
Speaker 2 (06:47):
Yeah, you need that validation.
Speaker 1 (06:49):
And the blueprints detail a very specific step for that.
You open up the terminal directly inside VS Code, and
you type the command. NET new console.
Speaker 2 (06:58):
Right, and that command initiates the scaffolding process. The. NET
framework interprets that instruction and just automatically generates the boilerplate
directory structure, the config files, and a basic C-sharp file.
With the classic Hello World application.
Speaker 1 (07:11):
Yeah, you hit enter and you can literally see the
files populate right there in the sidebar. It's so satisfying.
Speaker 2 (07:16):
It is.
Speaker 1 (07:17):
And then to prove the compilation pipeline is intact, you
follow up by typing. NET run. The framework compiles the
code on the fly and the words Hello World print
out in the terminal.
Speaker 2 (07:27):
Which seems trivial, I know.
Speaker 1 (07:29):
It does, but mechanically it proves our C Sharp toolchain
is fully operational.
Speaker 2 (07:34):
Exactly. It proves the intermediate language compiler is functioning, the
runtime environment is executing, and the standard output is routing
correctly back to your interface. The Windows red team environment
is officially established.
Speaker 1 (07:47):
Okay, so now that we have a workbench to forge
our tools, we obviously need an environment to test them against.
Speaker 2 (07:53):
Time for the target.
Speaker 1 (07:54):
Yes. The blueprints pivot us away from the familiar graphical
world of Windows, and they drop us directly into a
Linux Ubuntu system. We are transitioning from building local software
to constructing an internet-facing web server.
Speaker 2 (08:07):
Which requires an entirely different architectural mindset.
Speaker 1 (08:10):
Totally.
Speaker 2 (08:11):
Windows, in the context we just used it, is a
client-side environment. But Ubuntu, in this context, is going to
act as a host. It listens for external requests, processes data,
and serves content back across a network.
Speaker 1 (08:23):
And to build this hosting environment, the blueprints introduce a
classic trio, Apache, MySeal, and PHP.
Speaker 2 (08:30):
The legendary LMP stack.
Speaker 1 (08:32):
Exactly. Exactly. If you're listening to this and you've spent
any time around web infrastructure, you recognize this. Linux, Apache, MySQL, PHP.
Speaker 2 (08:40):
It's the backbone of so much of the web.
Speaker 1 (08:42):
It really is. We're setting up Apache to act as
the web demon, listening for HTTP requests. We're deploying MySQL
to establish a relational data mapping structure to hold persistent information.
And we're using PHP as the server-side scripting language to
process logic.
Speaker 2 (08:57):
Right. You're building a dynamic, stateful application infrastructure. And historically,
that is a prime target for red team exploitation.
Speaker 1 (09:04):
Because it's so common.
Speaker 2 (09:05):
Yeah. The LMP stack powers a massive percentage of the
dynamic web. If you want to understand how SQL injection
works or how cross-site scripting is executed, you have to
understand how these three specific technologies parse and pass data
between one another.
Speaker 1 (09:19):
But, you know, the method of installation here is a
stark contrast to what we just did on Windows. On Windows,
we downloaded a neat little executable and watched a graphical
progress bar.
Speaker 2 (09:27):
Nice and friendly.
Speaker 1 (09:28):
Very friendly. But here on the Ubuntu side, the blueprints
have us open a raw blank terminal screen. To get Apache,
we were typing sudo apt-get install apache2. Yep. We hit enter,
watch a wall of text fly by, and then type
sudo apt-get install my squalus server. I have to admit.
The first time you look at a blank Linux terminal,
(09:51):
it feels incredibly unforgiving.
Speaker 2 (09:53):
Oh, it's terrifying for beginners.
Speaker 1 (09:54):
Right. It feels like one typo and the computer is
just daring you to break it. Why this reliance on
the command line? line interface? Why the sudden shift?
Speaker 2 (10:03):
Well, it comes down to how production servers actually operate
in the real world. Most enterprise web servers are headless.
Speaker 1 (10:08):
Meaning no screen.
Speaker 2 (10:10):
Basically, yeah. They don't have a graphical user interface because
a GUI consumes valuable system resources, RAM and CPU cycles.
That should be strictly dedicated to serving web traffic. So
system administrators have to interact with these machines remotely via
secure shells.
Speaker 1 (10:25):
So you really just have to learn to speak to
the operating system without a mouse.
Speaker 2 (10:28):
Exactly. And honestly, the command line, specifically using a package
manager like AppGet, is infinitely more efficient.
Speaker 1 (10:35):
How so?
Speaker 2 (10:36):
The package manager automatically calculates dependency trees. When you tell
it to install Apache, it checks to see what other
underlying software libraries Apache needs to function. reaches out to
the Debian repositories, downloads them all, and installs them in
the correct order. Wow, okay. You're achieving in one line
of text what would take a dozen manual downloads in
(10:57):
a graphical environment.
Speaker 1 (10:59):
That automation becomes very apparent when the blueprints guide us
through installing PHP. It actually feels almost interactive.
Speaker 2 (11:06):
It's a great feature.
Speaker 1 (11:07):
Yeah. The instructions tell you to type sudo apt-get install php,
but before you hit enter, you press the tab key twice.
Speaker 2 (11:15):
Ah, tab completion. It's a lifesaver.
Speaker 1 (11:17):
It's brilliant. You double-tab, and the terminal basically pauses, queries
its repositories, and spits out a list of every available
PHP version you can install.
Speaker 2 (11:26):
Yeah, it shows you exactly what your options are.
Speaker 1 (11:28):
The blueprints note that version 7.2 is available, so we
just finish the command with PHP 7.2. The terminal isn't
just a blank slate anymore. It's actively helping you construct
the syntax.
Speaker 2 (11:39):
Which demonstrates that the command line shell is a dynamic environment.
It's constantly aware of the file system and the available
software indexes.
Speaker 1 (11:47):
Right. But we don't just install the base PHP package.
The blueprints are incredibly specific about the extensions we need
to add to that terminal command. We type in php-mysql.
Speaker 2 (11:59):
Which makes logical sense. PHP needs a specific driver to
communicate with the relational database.
Speaker 1 (12:05):
Exactly. Then we add PHP as main string to handle
multi-byte character encodings for complex data formats later on. But
then we hit the final extension, live Apache 2 mod THP.
Speaker 2 (12:16):
That is the crucial one.
Speaker 1 (12:17):
The blueprints refer to this as a crucial link, yeah.
But I really want to get under the hood here. Mechanically,
what is actually happening in the system memory when we
install this specific module?
Speaker 2 (12:26):
This is where the architecture of the web becomes super fascinating.
By default, Apache is a remarkably simple piece of software.
Its entire job is to receive an HTTP request, look
on the hard drive for a file matching that request,
and just send it back.
Speaker 1 (12:39):
Simple enough.
Speaker 2 (12:40):
Right. If you ask for an image, it sends the image.
But if you ask it for a PHP script, Apache
doesn't actually know how to execute code.
Speaker 1 (12:48):
Wait, so what would it do?
Speaker 2 (12:49):
It would just send you the raw, unexecuted text of
the script.
Speaker 1 (12:52):
Oh, which is a massive security risk if that script contains, say,
database passwords.
Speaker 2 (12:58):
Precisely. So Live Apache 2 Mod PHP acts as an
embedded translator. It installs a PHP interpreter directly inside Apache's
worker processes in the system memory.
Speaker 1 (13:08):
Okay.
Speaker 2 (13:09):
So when a request comes in for a PHP file,
Apache no longer tries to read it as a static document.
It hands the file off to this internal module. The
module compiles the script on the fly, executes the logic,
queries the database if necessary, and then generates standard HTML.
Speaker 1 (13:25):
Oh, wow.
Speaker 2 (13:25):
Yeah. And then it hands that HTML back to Apache,
which finally sends it to the user. The user never
sees the code. They only see the result.
Speaker 1 (13:31):
That is such an elegant piece of engineering. You are
physically bridging the gap. between a static web server and
a dynamic programming language. So we run that command. The
terminal cascades with text as it unpacks all those binaries.
The heavy machinery is installed. But if you are listening
to this and you've ever stared at a 500 internal
(13:52):
server error trying to load a local test page, you
know that downloading a package isn't the same as actually
running a service.
Speaker 2 (13:59):
Oh, yeah. That's a very common pitfall for beginners. The
package manager places the binaries on the hard drive, but
it doesn't always instantiate the runtime processes.
Speaker 1 (14:08):
Right. To solve this, the blueprints introduce a new syntax
for managing services, or daemons as they are called in Linux.
We type sudo service apache2 start. But we don't just
assume it worked. Immediately after, the blueprints require us to
type sudo service apache2 status.
Speaker 2 (14:26):
That status check is basically your diagnostic window. Demons run
in the background, detached from your terminal session. If Apache
fails to start, maybe another application is already occupying port 80,
or there's a typo in a configuration file, it will
crash silently in the background.
Speaker 1 (14:39):
And you would have absolutely no idea until you try
to load a web page and just got a connection timeout.
Speaker 2 (14:45):
Exactly. By running the status command, you force the operating
system to print out the active state of the demon
and the last few lines of its system log. If
it says active and running, your web server is alive.
If it says failed, the log will tell you exactly
which line in the config file caused the panic.
Speaker 1 (15:02):
It's like checking the heartbeat of a patient. You need
to know the server's alive before you try to use it.
Speaker 2 (15:07):
Right.
Speaker 1 (15:07):
So we follow the exact same procedure for the database,
running the start command for the MySQL service and checking
its status. Both demons are humming in the background. Our
Ubuntu engine room is officially online. Awesome. But the blueprints
introduce one final, crucial modification to our Linux environment. Once
the demons are running, we have a bit of a
workflow problem. Writing complex PHP logic in a raw terminal
(15:32):
editor like Nano or Vim can be, well, a formatting
and debugging nightmare for a lot of people.
Speaker 2 (15:37):
Yeah, I mean, while terminal editors are incredibly powerful, they
lack the visual affordances that speed up complex development cycles.
When you're writing hundreds of lines of code that dictate
how a web server interacts with a database, syntax highlighting
and visual directory mapping become pretty essential.
Speaker 1 (15:54):
Yeah, I can imagine. So to optimize the workflow, the
blueprints recommend installing the Atom coding editor. Now, they are
careful to note that Atom isn't strictly required for the
web server to function, but it drastically improves your coding capability,
like upgrading from a manual hand crank to a power drill.
That's a good analogy. To get it, we transition back
(16:16):
to a graphical browser on the Ubuntu desktop, navigate to Atom.io,
and download the Debian package file. We then use our
terminal to navigate to the downloads folder and install that
package directly into the operating system.
Speaker 2 (16:29):
And what you're doing here is bridging the gap between
server administration and software development. By installing a dedicated integrated
development environment, or IDE, on the Linux machine, you're creating
a space where you can rapidly prototype PHP code visually.
You save it and instantly have the Apache Daemon, which
is already running in the background process, and serve that code.
Speaker 1 (16:50):
And you launch it by simply typing Atom into the terminal.
The graphical editor opens up and you now have a
highly efficient visual workspace layered right on top of a
robust command line driven server infrastructure.
Speaker 2 (17:03):
It really is the best of both worlds. You have
the precision of the terminal for managing the daemons and
the efficiency of the IDE for writing the actual logic.
Speaker 1 (17:12):
So let's take a step back and survey the laboratory
we have just constructed through these blueprints. It is quite
an architectural feat.
Speaker 2 (17:19):
It really is a lot of ground covered.
Speaker 1 (17:21):
On one side of the network, we meticulously built a
Windows workbench. We installed a 32-bit. NET Core runtime to
ensure backwards compatibility for legacy exploits. We customized Visual Studio
Code with C-sharp intelligence to allow us to write tools
that interface natively with the Windows API. We named our
staging ground Red Team Develop, signaling its offensive purpose, and
(17:42):
we validated the entire compilation pipeline.
Speaker 2 (17:45):
Yeah, and on the other side, we utilized the speed
and automation of the Linux command line to deploy an
active target. We installed Apache to handle HTTP requests, MyCFL
to map relational data, and PHP to execute server-side logic.
Speaker 1 (18:00):
And we bridged that gap, too.
Speaker 2 (18:01):
Right. We fundamentally altered how Apache processes data by embedding
the LibApache2 mod PAP interpreter into its memory. Plus, we
verified that our background daemons were actively listening for connections.
Speaker 1 (18:14):
You now understand the blueprints to build the exact infrastructure
that professionals use to both build the web and break it.
But before we wrap up, I want to do a
quick mental exercise for you, the listener, to reinforce the
technical syntax we explored today.
Speaker 2 (18:27):
Oh, this is a good idea.
Speaker 1 (18:28):
Think back to our Windows setup right after we configured
our red team folder. Imagine you are staring at your
terminal and you need to generate the boilerplate scaffold for
a brand new C-sharp application. What two exact words do
you type immediately following the word. NET to execute that command?
I'll give you a second. Yeah, right. If you remember
new console, your foundational syntax is locked in. You are
(18:50):
well on your way.
Speaker 2 (18:51):
Today, we systematically built two separate islands of technology, a
Windows space configured for application development and a Linux environment
hosting a live web server. But consider this for your
own exploration as you move forward.
Speaker 1 (19:05):
Okay, what's that?
Speaker 2 (19:06):
In the real world of networks and security, these environments
are never really isolated. They exist on the same subnet.
They can see each other. So what do you think
happens when the specialized native C-sharp applications you compile on
that Windows Red Team machine Start actively probing the Apache
daemon across the network.
Speaker 1 (19:25):
Oh, wow.
Speaker 2 (19:25):
What happens when a tool you built tries to pass
a malicious multibyte string to the PHP interpreter on that
Ubuntu server? That intersection, the moment the lockpick meets the lock,
that is where the real security engineering begins.
Speaker 1 (19:37):
I love that. The workbench is set. The target server
is humming. The lab is officially open.
So if you want to catch a hacker, you don't
just set a trap. You kind of have to build
the exact hands they're going to break into.
Speaker 2 (00:05):
Right, yeah. And you have to literally forge the tools
to pick your own locks.
Speaker 1 (00:09):
Exactly. I mean, you have to understand the metology of
the lock, the tension of the springs, all the vulnerabilities
of the architecture before you can ever really hope to
secure it.
Speaker 2 (00:18):
Oh, absolutely.
Speaker 1 (00:19):
So today, we are analyzing a set of foundational technical blueprints.
And our mission for you, the listener... is to explore
how to actually construct both the locks and the lockpicks
from scratch. We're doing a deep dive into building a
dual environment development laboratory.
Speaker 2 (00:37):
Which is such a critical exercise for anyone who's, you know,
serious about technology.
Speaker 1 (00:41):
Yeah. So first, we'll construct a specialized Windows environment for
writing compiled software. And then we're going to pivot entirely
and configure a Linux Ubuntu system designed specifically to host
dynamic web services.
Speaker 2 (00:55):
Because, I mean, the environments we are about to break down,
they're not just simulations. These are the exact frameworks enterprise
developers use to build applications. And simultaneously, they're the exact
staging grounds cybersecurity professionals use to tear those same applications apart.
Speaker 1 (01:10):
Wow. So by building these two distinct nodes, you're essentially
creating a localized microcosm of the Internet itself.
Speaker 2 (01:18):
You really are, yeah.
Speaker 1 (01:19):
Okay, let's unpack this. Let's step into the first part
of this laboratory, the Windows Workspace. This is essentially our
application workbench.
Speaker 2 (01:26):
Right. The foundation.
Speaker 1 (01:27):
Yeah. So the blueprints initiate the process by having us
navigate to google.com, search for. NET Core, and head straight
to the official net.microsoft.com domain. But there's the detail here
that immediately jumped out at me.
Speaker 2 (01:42):
Oh, the 32-bit thing?
Speaker 1 (01:43):
Yes. The instructions explicitly specify downloading the 32-bit installer for.
NET Core and running that executable. I'll admit, that just
stopped me in my tracks.
Speaker 2 (01:52):
I mean, I completely get why.
Speaker 1 (01:53):
Right. Because in a modern computing environment, almost everything we
touch is 64-bit architecture. So why are these blueprints pointing
us backward to a 32-bit runtime? Like, is there a
strategic reason for that, especially if we were setting this
up for security testing down the line?
Speaker 2 (02:10):
That is an incredibly sharp observation. And yeah, there's a
huge strategic reason. When you are building a lab for
offensive security, backwards compatibility is just paramount.
Speaker 1 (02:20):
Because of older systems.
Speaker 2 (02:22):
Exactly. A lot of legacy enterprise systems, the ones that
often harbor the most critical vulnerabilities, they still rely on
32-bit architectures.
Speaker 1 (02:31):
Oh, wow. Okay, that makes sense. Yeah.
Speaker 2 (02:33):
And furthermore, when you're first learning how memory works, you know,
how to manipulate pointers or execute a buffer overflow... A
32-bit memory address space is just significantly easier to map
out and understand than a 64-bit space.
Speaker 1 (02:49):
Oh, so it's practically a learning tool in itself.
Speaker 2 (02:51):
It really is. By forcing the environment into a 32-bit architecture,
the blueprints ensure that the payloads and tools you eventually
build will actually execute effectively against older, vulnerable targets without
some sort of architectural mismatch.
Speaker 1 (03:05):
I hadn't even considered the legacy aspect. You're essentially making
sure your digital lockpick gets into the older rusted locks
that organizations just forget to replace.
Speaker 2 (03:14):
That's a perfect way to put it.
Speaker 1 (03:15):
So, okay, we run the executable, the framework installs, and
the underlying concrete is poured. But a runtime environment doesn't
really help you write the code itself.
Speaker 2 (03:24):
No, not at all. You need a workbench. Right.
Speaker 1 (03:28):
The next progression in the blueprint is downloading Visual Studio Code.
And they make a specific point to mention that VS
Code is completely free, which is great. But as a
raw download, I mean, it's just a text editor.
Speaker 2 (03:41):
Yeah, it's essentially a blank slate at first. VS Code
is built on an extensible architecture. So out of the box,
it lacks the compilers, debuggers, the language-specific intelligence for heavy-duty development.
You have to mold it.
Speaker 1 (03:54):
And that molding process brings us to the next step.
Speaker 2 (03:56):
Yeah.
Speaker 1 (03:57):
So you open the app, navigate to the extensions menu.
And search for C Sharp. That's the letter C followed
by the pound sign. You install the very first extension
that pops up. But I do want to push back
on the language choice here. Okay.
Speaker 2 (04:08):
What are you thinking?
Speaker 1 (04:09):
Well, when I think of offensive security or, you know,
rapid application development, I usually think of Python for scripting
or maybe C + + for low-level memory access. Why
are the blueprints steering us towards C Sharp on a
Windows machine?
Speaker 2 (04:22):
I get that. But C Sharp actually provides a unique
tactical advantage in a Windows environment. Because Microsoft developed it,
C Sharp hooks natively and seamlessly right into the Windows API.
Speaker 1 (04:34):
Oh, the application programming interface.
Speaker 2 (04:36):
Right. So this allows developers or security testers to interact
directly with the operating system's core functions.
Speaker 1 (04:42):
Whereas Python wouldn't do that as easily.
Speaker 2 (04:44):
Well, if you write a tool in Python, it often
requires a heavy interpreter. and modern endpoint detection systems, they
can flag malicious Python scripts almost immediately. C Sharp, on
the other hand, it compiles into an intermediate language that
runs within the. NET framework. It just blends in. To
a security system, a well-written C Sharp executable often just
(05:06):
looks like normal enterprise software going about its day.
Speaker 1 (05:09):
Wow, so it's camouflage. You are building tools that speak
the native dialect of the target operating system.
Speaker 2 (05:16):
That's fascinating. And I guess that leads perfectly into the
naming convention the blueprints require next.
Speaker 1 (05:21):
Ah, yes, the folder name. Right.
Speaker 2 (05:24):
We are instructed to go to the desktop and create
a new project folder. But the instructions are really rigid here.
You must name this folder Red Team Develop.
Speaker 1 (05:34):
Yeah, they don't leave any room for interpretation there.
Speaker 2 (05:36):
They don't. They emphasize this folder will be the nucleus
for the rest of the curriculum. And I want to
unpack this term for the listener because Red Team... carries
a ton of weight in the industry.
Speaker 1 (05:47):
It really does. In cybersecurity, you basically have the blue team,
which defends the network, and the red team, which attacks it.
Speaker 2 (05:55):
Right.
Speaker 1 (05:55):
But red teaming isn't just, you know, randomly throwing exploits
at a firewall. It's a highly structured adversarial simulation. Red
teamers act as advanced persistent threats. They conduct reconnaissance, weaponize payloads,
and attempt to exploit vulnerabilities to achieve a specific objective.
Speaker 2 (06:12):
All without being detected. Right.
Speaker 1 (06:14):
All under the radar. So by naming this foundational workspace
Red Team Develop, the blueprints are really planting a flag
in the ground. We aren't setting up this C-sharp environment
to build some generic payroll app.
Speaker 2 (06:26):
No, not at all.
Speaker 1 (06:28):
We are staging the workbench to forge offensive capabilities.
Speaker 2 (06:32):
Precisely. You are building the armory.
Speaker 1 (06:35):
I love that. But an armory is pretty useless if
the forge doesn't actually fire up.
Speaker 2 (06:40):
Right.
Speaker 1 (06:40):
We have to verify that the. NET framework, VS Code,
and the C-sharp extension are actually talking to each other.
Speaker 2 (06:47):
Yeah, you need that validation.
Speaker 1 (06:49):
And the blueprints detail a very specific step for that.
You open up the terminal directly inside VS Code, and
you type the command. NET new console.
Speaker 2 (06:58):
Right, and that command initiates the scaffolding process. The. NET
framework interprets that instruction and just automatically generates the boilerplate
directory structure, the config files, and a basic C-sharp file.
With the classic Hello World application.
Speaker 1 (07:11):
Yeah, you hit enter and you can literally see the
files populate right there in the sidebar. It's so satisfying.
Speaker 2 (07:16):
It is.
Speaker 1 (07:17):
And then to prove the compilation pipeline is intact, you
follow up by typing. NET run. The framework compiles the
code on the fly and the words Hello World print
out in the terminal.
Speaker 2 (07:27):
Which seems trivial, I know.
Speaker 1 (07:29):
It does, but mechanically it proves our C Sharp toolchain
is fully operational.
Speaker 2 (07:34):
Exactly. It proves the intermediate language compiler is functioning, the
runtime environment is executing, and the standard output is routing
correctly back to your interface. The Windows red team environment
is officially established.
Speaker 1 (07:47):
Okay, so now that we have a workbench to forge
our tools, we obviously need an environment to test them against.
Speaker 2 (07:53):
Time for the target.
Speaker 1 (07:54):
Yes. The blueprints pivot us away from the familiar graphical
world of Windows, and they drop us directly into a
Linux Ubuntu system. We are transitioning from building local software
to constructing an internet-facing web server.
Speaker 2 (08:07):
Which requires an entirely different architectural mindset.
Speaker 1 (08:10):
Totally.
Speaker 2 (08:11):
Windows, in the context we just used it, is a
client-side environment. But Ubuntu, in this context, is going to
act as a host. It listens for external requests, processes data,
and serves content back across a network.
Speaker 1 (08:23):
And to build this hosting environment, the blueprints introduce a
classic trio, Apache, MySeal, and PHP.
Speaker 2 (08:30):
The legendary LMP stack.
Speaker 1 (08:32):
Exactly. Exactly. If you're listening to this and you've spent
any time around web infrastructure, you recognize this. Linux, Apache, MySQL, PHP.
Speaker 2 (08:40):
It's the backbone of so much of the web.
Speaker 1 (08:42):
It really is. We're setting up Apache to act as
the web demon, listening for HTTP requests. We're deploying MySQL
to establish a relational data mapping structure to hold persistent information.
And we're using PHP as the server-side scripting language to
process logic.
Speaker 2 (08:57):
Right. You're building a dynamic, stateful application infrastructure. And historically,
that is a prime target for red team exploitation.
Speaker 1 (09:04):
Because it's so common.
Speaker 2 (09:05):
Yeah. The LMP stack powers a massive percentage of the
dynamic web. If you want to understand how SQL injection
works or how cross-site scripting is executed, you have to
understand how these three specific technologies parse and pass data
between one another.
Speaker 1 (09:19):
But, you know, the method of installation here is a
stark contrast to what we just did on Windows. On Windows,
we downloaded a neat little executable and watched a graphical
progress bar.
Speaker 2 (09:27):
Nice and friendly.
Speaker 1 (09:28):
Very friendly. But here on the Ubuntu side, the blueprints
have us open a raw blank terminal screen. To get Apache,
we were typing sudo apt-get install apache2. Yep. We hit enter,
watch a wall of text fly by, and then type
sudo apt-get install my squalus server. I have to admit.
The first time you look at a blank Linux terminal,
(09:51):
it feels incredibly unforgiving.
Speaker 2 (09:53):
Oh, it's terrifying for beginners.
Speaker 1 (09:54):
Right. It feels like one typo and the computer is
just daring you to break it. Why this reliance on
the command line? line interface? Why the sudden shift?
Speaker 2 (10:03):
Well, it comes down to how production servers actually operate
in the real world. Most enterprise web servers are headless.
Speaker 1 (10:08):
Meaning no screen.
Speaker 2 (10:10):
Basically, yeah. They don't have a graphical user interface because
a GUI consumes valuable system resources, RAM and CPU cycles.
That should be strictly dedicated to serving web traffic. So
system administrators have to interact with these machines remotely via
secure shells.
Speaker 1 (10:25):
So you really just have to learn to speak to
the operating system without a mouse.
Speaker 2 (10:28):
Exactly. And honestly, the command line, specifically using a package
manager like AppGet, is infinitely more efficient.
Speaker 1 (10:35):
How so?
Speaker 2 (10:36):
The package manager automatically calculates dependency trees. When you tell
it to install Apache, it checks to see what other
underlying software libraries Apache needs to function. reaches out to
the Debian repositories, downloads them all, and installs them in
the correct order. Wow, okay. You're achieving in one line
of text what would take a dozen manual downloads in
(10:57):
a graphical environment.
Speaker 1 (10:59):
That automation becomes very apparent when the blueprints guide us
through installing PHP. It actually feels almost interactive.
Speaker 2 (11:06):
It's a great feature.
Speaker 1 (11:07):
Yeah. The instructions tell you to type sudo apt-get install php,
but before you hit enter, you press the tab key twice.
Speaker 2 (11:15):
Ah, tab completion. It's a lifesaver.
Speaker 1 (11:17):
It's brilliant. You double-tab, and the terminal basically pauses, queries
its repositories, and spits out a list of every available
PHP version you can install.
Speaker 2 (11:26):
Yeah, it shows you exactly what your options are.
Speaker 1 (11:28):
The blueprints note that version 7.2 is available, so we
just finish the command with PHP 7.2. The terminal isn't
just a blank slate anymore. It's actively helping you construct
the syntax.
Speaker 2 (11:39):
Which demonstrates that the command line shell is a dynamic environment.
It's constantly aware of the file system and the available
software indexes.
Speaker 1 (11:47):
Right. But we don't just install the base PHP package.
The blueprints are incredibly specific about the extensions we need
to add to that terminal command. We type in php-mysql.
Speaker 2 (11:59):
Which makes logical sense. PHP needs a specific driver to
communicate with the relational database.
Speaker 1 (12:05):
Exactly. Then we add PHP as main string to handle
multi-byte character encodings for complex data formats later on. But
then we hit the final extension, live Apache 2 mod THP.
Speaker 2 (12:16):
That is the crucial one.
Speaker 1 (12:17):
The blueprints refer to this as a crucial link, yeah.
But I really want to get under the hood here. Mechanically,
what is actually happening in the system memory when we
install this specific module?
Speaker 2 (12:26):
This is where the architecture of the web becomes super fascinating.
By default, Apache is a remarkably simple piece of software.
Its entire job is to receive an HTTP request, look
on the hard drive for a file matching that request,
and just send it back.
Speaker 1 (12:39):
Simple enough.
Speaker 2 (12:40):
Right. If you ask for an image, it sends the image.
But if you ask it for a PHP script, Apache
doesn't actually know how to execute code.
Speaker 1 (12:48):
Wait, so what would it do?
Speaker 2 (12:49):
It would just send you the raw, unexecuted text of
the script.
Speaker 1 (12:52):
Oh, which is a massive security risk if that script contains, say,
database passwords.
Speaker 2 (12:58):
Precisely. So Live Apache 2 Mod PHP acts as an
embedded translator. It installs a PHP interpreter directly inside Apache's
worker processes in the system memory.
Speaker 1 (13:08):
Okay.
Speaker 2 (13:09):
So when a request comes in for a PHP file,
Apache no longer tries to read it as a static document.
It hands the file off to this internal module. The
module compiles the script on the fly, executes the logic,
queries the database if necessary, and then generates standard HTML.
Speaker 1 (13:25):
Oh, wow.
Speaker 2 (13:25):
Yeah. And then it hands that HTML back to Apache,
which finally sends it to the user. The user never
sees the code. They only see the result.
Speaker 1 (13:31):
That is such an elegant piece of engineering. You are
physically bridging the gap. between a static web server and
a dynamic programming language. So we run that command. The
terminal cascades with text as it unpacks all those binaries.
The heavy machinery is installed. But if you are listening
to this and you've ever stared at a 500 internal
(13:52):
server error trying to load a local test page, you
know that downloading a package isn't the same as actually
running a service.
Speaker 2 (13:59):
Oh, yeah. That's a very common pitfall for beginners. The
package manager places the binaries on the hard drive, but
it doesn't always instantiate the runtime processes.
Speaker 1 (14:08):
Right. To solve this, the blueprints introduce a new syntax
for managing services, or daemons as they are called in Linux.
We type sudo service apache2 start. But we don't just
assume it worked. Immediately after, the blueprints require us to
type sudo service apache2 status.
Speaker 2 (14:26):
That status check is basically your diagnostic window. Demons run
in the background, detached from your terminal session. If Apache
fails to start, maybe another application is already occupying port 80,
or there's a typo in a configuration file, it will
crash silently in the background.
Speaker 1 (14:39):
And you would have absolutely no idea until you try
to load a web page and just got a connection timeout.
Speaker 2 (14:45):
Exactly. By running the status command, you force the operating
system to print out the active state of the demon
and the last few lines of its system log. If
it says active and running, your web server is alive.
If it says failed, the log will tell you exactly
which line in the config file caused the panic.
Speaker 1 (15:02):
It's like checking the heartbeat of a patient. You need
to know the server's alive before you try to use it.
Speaker 2 (15:07):
Right.
Speaker 1 (15:07):
So we follow the exact same procedure for the database,
running the start command for the MySQL service and checking
its status. Both demons are humming in the background. Our
Ubuntu engine room is officially online. Awesome. But the blueprints
introduce one final, crucial modification to our Linux environment. Once
the demons are running, we have a bit of a
workflow problem. Writing complex PHP logic in a raw terminal
(15:32):
editor like Nano or Vim can be, well, a formatting
and debugging nightmare for a lot of people.
Speaker 2 (15:37):
Yeah, I mean, while terminal editors are incredibly powerful, they
lack the visual affordances that speed up complex development cycles.
When you're writing hundreds of lines of code that dictate
how a web server interacts with a database, syntax highlighting
and visual directory mapping become pretty essential.
Speaker 1 (15:54):
Yeah, I can imagine. So to optimize the workflow, the
blueprints recommend installing the Atom coding editor. Now, they are
careful to note that Atom isn't strictly required for the
web server to function, but it drastically improves your coding capability,
like upgrading from a manual hand crank to a power drill.
That's a good analogy. To get it, we transition back
(16:16):
to a graphical browser on the Ubuntu desktop, navigate to Atom.io,
and download the Debian package file. We then use our
terminal to navigate to the downloads folder and install that
package directly into the operating system.
Speaker 2 (16:29):
And what you're doing here is bridging the gap between
server administration and software development. By installing a dedicated integrated
development environment, or IDE, on the Linux machine, you're creating
a space where you can rapidly prototype PHP code visually.
You save it and instantly have the Apache Daemon, which
is already running in the background process, and serve that code.
Speaker 1 (16:50):
And you launch it by simply typing Atom into the terminal.
The graphical editor opens up and you now have a
highly efficient visual workspace layered right on top of a
robust command line driven server infrastructure.
Speaker 2 (17:03):
It really is the best of both worlds. You have
the precision of the terminal for managing the daemons and
the efficiency of the IDE for writing the actual logic.
Speaker 1 (17:12):
So let's take a step back and survey the laboratory
we have just constructed through these blueprints. It is quite
an architectural feat.
Speaker 2 (17:19):
It really is a lot of ground covered.
Speaker 1 (17:21):
On one side of the network, we meticulously built a
Windows workbench. We installed a 32-bit. NET Core runtime to
ensure backwards compatibility for legacy exploits. We customized Visual Studio
Code with C-sharp intelligence to allow us to write tools
that interface natively with the Windows API. We named our
staging ground Red Team Develop, signaling its offensive purpose, and
(17:42):
we validated the entire compilation pipeline.
Speaker 2 (17:45):
Yeah, and on the other side, we utilized the speed
and automation of the Linux command line to deploy an
active target. We installed Apache to handle HTTP requests, MyCFL
to map relational data, and PHP to execute server-side logic.
Speaker 1 (18:00):
And we bridged that gap, too.
Speaker 2 (18:01):
Right. We fundamentally altered how Apache processes data by embedding
the LibApache2 mod PAP interpreter into its memory. Plus, we
verified that our background daemons were actively listening for connections.
Speaker 1 (18:14):
You now understand the blueprints to build the exact infrastructure
that professionals use to both build the web and break it.
But before we wrap up, I want to do a
quick mental exercise for you, the listener, to reinforce the
technical syntax we explored today.
Speaker 2 (18:27):
Oh, this is a good idea.
Speaker 1 (18:28):
Think back to our Windows setup right after we configured
our red team folder. Imagine you are staring at your
terminal and you need to generate the boilerplate scaffold for
a brand new C-sharp application. What two exact words do
you type immediately following the word. NET to execute that command?
I'll give you a second. Yeah, right. If you remember
new console, your foundational syntax is locked in. You are
(18:50):
well on your way.
Speaker 2 (18:51):
Today, we systematically built two separate islands of technology, a
Windows space configured for application development and a Linux environment
hosting a live web server. But consider this for your
own exploration as you move forward.
Speaker 1 (19:05):
Okay, what's that?
Speaker 2 (19:06):
In the real world of networks and security, these environments
are never really isolated. They exist on the same subnet.
They can see each other. So what do you think
happens when the specialized native C-sharp applications you compile on
that Windows Red Team machine Start actively probing the Apache
daemon across the network.
Speaker 1 (19:25):
Oh, wow.
Speaker 2 (19:25):
What happens when a tool you built tries to pass
a malicious multibyte string to the PHP interpreter on that
Ubuntu server? That intersection, the moment the lockpick meets the lock,
that is where the real security engineering begins.
Speaker 1 (19:37):
I love that. The workbench is set. The target server
is humming. The lab is officially open.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by Audiochuck Media Company.
The Clay Travis and Buck Sexton Show
The Clay Travis and Buck Sexton Show. Clay Travis and Buck Sexton tackle the biggest stories in news, politics and current events with intelligence and humor. From the border crisis, to the madness of cancel culture and far-left missteps, Clay and Buck guide listeners through the latest headlines and hot topics with fun and entertaining conversations and opinions.