Back in college, I was part of a hacking club. We practiced throughout the school year and then

traveled to a nearby state to compete in a hacking competition against other universities.

I learned more here than I did in class, so if you're in college and listening to this,

try to join one at your school or one in the local area if it exists. At this

event, we faced off against other schools and industry blockhats who volunteered to try and

breach each school's mock network. Each team had a separate room they would work from for the

duration of the competition, and inside that room was five servers and two workstations. Those five

servers ran seven different services, like web, email, and Active Directory, that your team was

responsible for managing and making sure they were always up and running. The premise was that your

team had been hired to take over the company's network after the previous IT team had quit.

There was no documentation and no one to ask for help. Throughout the competition, you would receive

various requests from the CEO, many of which were far from ideal from a security standpoint. For example,

you might get a request like, hey, I was talking to a friend at another company, and they suggested we

expose our database to the internet. Please make that happen. While they weren't always that absurd,

they were close. The goal was to mimic real-world corporate scenarios. If you've ever worked at a

medium-to-large-sized company, or any company for that matter, you've probably experienced the fact

that security is often not a top priority. Crazy requests that seem obviously dangerous are

surprisingly common. While this was all happening, your services were being monitored. For every minute

they stayed operational, your team earned points. If your services went down, you stopped earning points,

and other teams could take the lead. What made it even more intense was the red team, composed of

black hats whose mission was to breach your network. Their goal was to break in, steal data, take your

services down, and generally make your life as difficult as possible. Facing off against real hackers

in a simulated digital environment was thrilling. It was one hell of an experience, and we looked

forward to it every year. It's where I first learned about the immutable attribute in Linux,

chatter plus I, when I couldn't delete a malicious file on one of the systems. Check it out.

To prepare for the competition, we would meet every week to practice. We set up services, attacked each

other's systems, and did everything we could to recreate the competition environment as closely as possible.

Out of all the preparation we did, one thing stands out in my memory.

MS-08-067, also known as CVE-2008-4250.

This exploit allowed remote attackers to gain system-level access to a Windows computer.

Using Metasploit, it took just three commands to exploit a system and gain full control.

Our networking teacher, who also happened to be the advisor for the hacking club,

would set up a cluster of Windows machines for different classes to use for practice or

various projects. My friend and I would often go to the lab in the evenings to practice and to try

and break things. I'll never forget how reliably MS-08-067 worked. We'd run the exploit, gain access to all

hosts in the cluster, wipe them, and then laugh the next morning when our teacher was scratching his head

in class, wondering why he had to keep restoring the virtual machines from snapshots. Good times.

While we were just having fun, something far more malicious was happening in the wild.

The same exploit we were just playing with was being used by Conficker. This malware wreaked havoc on the

world. From exploiting our PC to leveraging a pool of 50,000 domains to download updates on this episode

of In the Shell.

...without the operator's knowledge...

...and if it sounds malicious, it's because it is.

...40 attacks just this year on educational organizations...

...and now to the massive cyber attack targeting hotels and casinos in Las Vegas...

...to a possible cyber attack at one of the nation's busiest airports...

...a cyber security firm, CrowdStrike, has caused this outage...

...that it takes you longer to do something by putting it into a computer and calling it up again than

...if you just kept simple records yourself.

from the house.

Conficker had a few other names it was known by. Down Up, Down A.D. Up, and Kaido. There's also a

couple theories about where the name came from. It's thought to be a combination of the English

term configure and the German pejorative ficker, which translates to the English word f***er.

Pretty creative if you ask me. The first variant of Conficker was discovered in early November

2008. It propagated through the internet by exploiting a vulnerability in a network service

on Windows 2000, XP, Vista, Server 2003, Server 2008, and Server 2008 R2 Beta. That vulnerability

it exploited, which I mentioned in the intro, was MS08-067. Like I said, it exploited a vulnerability

in a place where you can see myождically.

khi

a network service on Windows, and that service was RPC. RPC, which is short for Remote Procedure

Call, is a foundational technology that enables communication between programs,

not just on the same computer, but across a network. At its core, RPC allows one program

to execute a function or procedure on another system as if it were a local operation. Think

of it as a remote control for code, letting one computer tell another, hey, run this function

for me. So here's how it works. Imagine your program needs to perform a task that resides

in another machine. With RPC, it sends a request to the remote machine, which processes the request,

executes the task, and sends back the results. The magic lies in abstraction. All the complexities

of network communication.

like creating requests and parsing responses, are handled automatically, making the process seamless for developers.

RPC operates in a client-server model.

The client, your program, initiates the request, while the server, the remote machine or service,

executes the requested action and returns the results.

It's protocol agnostic, meaning RPC can work over different transport protocols depending on the implementation.

For example, Microsoft RPC, ms-rpc, often uses the DCE, Distributed Computing Environment, standard,

which supports communication over TCP IP.

For example, it powers network file sharing and printer access.

It supports key services like Active Directory, Windows Management Instrumentation, WMS.

and the distributed component object model, DCOM. In short, if you've ever accessed a shared folder

or used a networked printer on Windows, RPC was silently working in the background to make that

happen. Now here's where things get tricky. Because RPC allows remote systems to execute tasks,

it's a prime target for attackers if it's not secured. Vulnerabilities like MS08-067,

which I'm going to refer to now as MS08, exploited weaknesses in the RPC implementation,

giving attackers a way to run malicious code with system-level privileges. This is why keeping

RPC services patched and properly configured is so important. Despite its age, RPC is still widely

used in modern networks, especially within Windows environments. However, newer technologies and

psychologists get there. Let's do that. Let's see.

Let's go back to the next slide.

security measures have improved its resilience. So RPC, that's what Configure exploited to gain

access to a system. From there, it needed to spread, and it did that using NetBIOS services

and SMB. NetBIOS, short for Network Basic Input slash Output System, is a fundamental part of

older networking systems that you've probably encountered if you've worked with local networks

or older Windows computers. NetBIOS isn't a protocol per se, it's more like a translator that

helps applications on different devices communicate over a network. Think of it as a middleman for name

resolution, session management, and data sharing in local networks. So for name resolution, let's say

your computer wants to find another computer named Office PC on the network. Instead of having to know

an IP address,

NetBiOS steps in to map that simple name to the device.

For session management, once two devices know about each other, they need to set up a session,

a kind of virtual handshake, to keep communication running smoothly.

And lastly, it facilitates data sharing, like transferring files or printing a document over

the network. While MS08 was Configure's entry point, NetBiOS played a critical role in its

rapid spread. NetBiOS allowed the worm to enumerate systems and shares on the network,

and then propagate itself by exploiting weak credentials or default passwords on shared

resources. Here's an example on how that worked. Configure first used NetBiOS to discover computers

and shared folders on a network. It targeted the admin share visible over NetBiOS. If that share

was password protected, Configure launched a dictionary attack.

Tempting to guess the password using a list of common or default credentials, these attacks generated large amounts of network traffic, sometimes triggering account lockouts.

Once access was gained, Conficker copied itself to shared drives and folders, ensuring it could infect additional systems.

NetBIOS wasn't the vulnerability, but a tool Conficker leveraged to spread laterally across networks.

Combined with SMB and other mechanisms, this made Conficker especially effective at propagation.

But Conficker didn't stop there.

Variants like Conficker B and C used removable media like USB drives to spread.

They placed a copy of the virus in Recycle.bin, which meant it would be hidden from someone just casually browsing the drive, and manipulated the autorun.inf file to execute the malware when the drive was plugged into a new machine.

Configure also added registry keys to ensure it launched itself on system boot.

Configure wasn't just another piece of malware.

It was a meticulously designed, modular worm that incorporated several techniques to infect, adapt, and persist.

Configure had multiple ways to deliver and update its payloads.

These updates allowed it to evolve into newer, more advanced variants.

Variant A generated 250 domain names daily across five top-level domains, TLDs, using a pseudo-random number generator, PRNG.

Infected machines would then try to connect to these domains to pull updates.

The PRNG ensured all copies of the worm generated the same domain names each day, creating a decentralized update mechanism.

Variant B increased to eight TLDs and generated domain names.

disjoint from Variant A, further diversifying its control structure.

Variant D took this to another level, generating 50,000 domain names daily across 110 TLDs,

randomly selecting 500 to contact. This made detection nearly impossible and added resilience

to its update mechanisms. And if that wasn't bad enough, Conficker started to use peer-to-peer

networking. Variant's D&E created a decentralized peer-to-peer network. This allowed infected

hosts to exchange payloads directly, bypassing traditional command and control servers.

Large-scale UDP scanning built up a list of peers, while TCP connections transferred encrypted and

signed payloads. And of course, like any good malware, to prevent tampering, Conficker used

encryption. Variant A payloads were hashed with SHA-1, encrypted with RC-4,

and then RSA signed with a 1024-bit private key. They put more effort into their security than

most modern-day companies. Later variants switched to MD6 and expanded RSA keys to 4096-bits

to stay ahead of potential weaknesses in the cryptographic algorithms. These measures ensured

that only payloads signed by the Worms creators could be executed. It also had some creative

self-defense mechanisms built in. Configure changed the ownership of its DLL file to a special user

account called System. Now what's so special about System? In Windows, System is the most powerful

account. It's the account the operating system itself uses to perform tasks. Even if you are an

administrator on the computer, you don't have the same level of access as System does. This means

that once Configure assigned its files to System, even Administrator,

people who are supposed to have complete control, couldn't delete or modify those files without some

serious effort. But Conficker didn't stop there. It also made a backup copy of its DLL file,

cleverly disguising itself as a JPG image hiding in the Internet Explorer cache,

so even if someone managed to delete the original file, Conficker could restore itself from the

backup, staying active and ready. If I'm being honest, Conficker has a better backup and restore

process than I do. It also disabled key system services, such as Windows Automatic Update,

Security Center, Defender, and error reporting. Nice. Conficker even terminated processes related

to antivirus software and diagnostic tools. And like Malware I mentioned in previous episodes,

it blocked access to antivirus websites in the Windows Update service by patching the system

some Resolver DLL, to prevent DNS lickups for those hosts.

Despite a patch for MS08 being available when the worm emerged,

millions of systems remained vulnerable.

It's both funny and sad that with each episode I make about some global worm or malware,

I keep saying the same thing over and over.

There's an exploit, a patch is available, and people don't patch.

So take this as your reminder to make sure you update all your devices

and don't use any end-of-life devices.

Now with that out of the way, back to the episode.

Conficker is estimated to have infected 7 million systems,

including government networks, hospitals, and critical infrastructure.

Its peer-to-peer network remains active to this day in some networks,

a small reminder of how difficult it is to eradicate such threats.

The chilling part of Conficker's story is that it never unleashed its full...

potential. Its creators demonstrated restraint, perhaps unwilling to trigger a global retaliation,

but the groundwork was there. Configure could have been used to launch massive DDoS attacks,

steal sensitive data or install ransomware. Its decentralized architecture, robust encryption,

and ability to adapt inspired later worms that did cause devastating damage.

Configure wasn't just a one-time crisis, it was a test. And in many ways, we failed.

By 2017, NotPetya exploited similar negligence in patching systems, showing that the lessons of

Configure weren't fully absorbed. Configure demonstrated how the combination of human

negligence, outdated systems, and sophisticated malware could cripple networks. The fact that

Configure remains in the wild today, dormant but undefeated,

as a reminder of how much work remains to secure the digital world.

In the Shell is written, researched, and recorded by me, the Podficker.

Please share this episode with someone you think would enjoy it.

Maybe copy it to a few network shares.

It's what Conficker would want you to do.

That's it. Take care, and I'll see you next time.