Update: 6/17/2025: This talk has been remastered! New features include: New, updated textures! A more experienced speaker! Best of all, COOP mode! See what’s new in talk about hacking Skyrim in a pretty bad ass way! : BSides Buffalo New York 2025
Update: 8/7/2024: This talk was presented live at BSides Las Vegas 2024. The following link will provide the slide deck for that talk: BSidesLV 2024 slides
The following is the YouTube link to the talk: BSidesLV 2024 Talk
Hello fellow code conjurers and digital Nightblades! We’ve embarked on our first technical blog, and it’s a dragon-sized adventure through the realms of Skyrim and hacking. Get ready for a Fus Ro Dah of a time!
This is the kind of content we imagined creating while sitting in a hallway at BSides Las Vegas just months ago, discussing the idea of setting up this site. So, what are we doing in our first ever technical blog you ask? We really wanted something creative, fun, and unique. We wanted something that will challenge us to do something new to us, requiring research, development, and testing.
To get the most out of this write up, you’re going to want to know about two things: what Skyrim is and what a reverse shell entails.
We here at Hexxed BitHeadz love Skyrim, one of the most popular RPG adventures ever. It’s our most played single player game in our library. We also have a lot of fun modding Skyrim. With the insanely beautiful texture packs, intense spells, DLC sized adventures and incredible weapons and armor skins, who wouldn’t?
At some point in our spiral of modding obsession, we noticed a “Virus scan: safe to use” label on the mod provider site. At the time, it never occurred to us that there could be malicious Skyrim mods… how would that even work?! What would that even look like?! The questions were there, but neither one of us had any of the skill set to know how to answer.
Well fellow Dragonborn-ers, we have dedicated the last 5 years of our lives to hacking studies and answering this one question! Just kidding, we found a passion for all things hacking and look forward to sharing our journey as we progress. So, we are demonstrating what a malicious mod can look like for Skyrim! What does it do? It lingers around until a specific item is picked up by the character in game, triggering the spawn of a reverse shell to an attacker host! What in game item triggers this malicious action? The item is called “Meridia’s Beacon”. Why this item specifically? Well, we have been diving into command & control frameworks lately and thought that it would be ironic that an in-game item named “Meridia’s beacon” will be used to spawn a real C2 beacon. That’s right Beacon Buddies, not only will we catch a netcat reverse shell, but we’ll also transform our payload into a full-blown C2 beacon!
Welcome to our technical blog: A New Host Touches the Beacon
NOTE: Our topic is not a vulnerability within Skyrim itself. The process outlined here requires the target to download and install a specific modding framework. We are not in any way reverse engineering the original software, instead we are abusing an existing framework that has already done the reverse engineering. Initial setup steps will not be presented in this blog post, as this is not meant to be a full walk through of how to do this, simply an article for modding awareness. Milestone POC’s will be presented on our GitHub. This article is intended for educational and awareness purposes only.
Also, please excuse the in-game video quality, we had 3 VMs running with no proper graphics support, but it got the job done. 😁
Overview of milestones:
Now, we’re going to list out our thought process. A project like this is new to us, and we knew this was going to require a good amount of research, development, and testing. Below, you will find our planned milestones to achieve our final goal:
- Get an action outside of the game to execute on a specific in-game event.
- Find a way to identify the desired in-game item.
- Get that action from step 1 to execute when step 2 condition is met.
- Get a reverse shell when our desired in-game item is picked up by the player.
- Get a C2 beacon callback when step 1 and step 2 conditions are met.
Alright, enough lollygaggin’, let’s get to hack’n!
With Skyrim downloaded, Our next step was to explore the use of an existing framework popular amongst modders to extend scripting capabilities within Skyrim mod creation. We utilized this framework to create our mod, dedicating several sessions to understanding Visual Studio 2022 with C++ support and how to set up a basic Skyrim mod. After some trial and error and utilizing a template already equipped for logging and further development, we successfully crafted a mod! The following template was utilized as our starting point.
We conducted enough research to assemble a simple mod. It logs specific details when a player strikes something in the game. This served as a solid foundation for our experimentation. Once the code is in place, it compiles out to a DLL file. It raised a question: what more could we achieve besides simple logging when a player strikes something in the game? Could we execute external programs in Windows, such as the calculator, by inserting a system call into the source code, compiling the mod DLL file, placing it in our mod folder, firing up Skyrim, and hitting something to launch calculator.exe? The answer is a resounding ‘Yes, we can!’ Below, we present our proof of concept and guide you through it.”
We begin our C++ code by defining a class and inheriting from BSTEventSink, which handles events of the TESHitEvent type. This event type is used specifically so we can understand what happens when the hit event is called. Next, we assign two variables used to get the source and target names of when an object is hit. This information is logged, and that was the end of the original code, before adding our lines of code. Those lines being the calling of calc.exe, found just under the target and source variable declarations. The final section of code at the bottom is simply used as an entry point for loading the plugin into the game. At this point, we compile the code, and ensure that the newly generated DLL mod file ends up in the correct Skyrim directory to be read by the game when loaded. In the video below, we demonstrate the desired results for our first milestone.
This was interesting to us because we successfully established a correlation, when something in-game occurred, we managed to make something outside the game execute….. However, the end goal was not to execute calculator.exe whenever something was struck, so the next research sessions were to answer how to write a condition statement saying basically:
if (player picks up Meridia's Beacon):
run calc.exeWe now begin to tackle milestone #2. How does the game understand what “Meridia’s Beacon” is? Well with some more research, we learn that items have a FormID. The formID for Meridia’s Beacon is 0004E4E6, which was found on Elder Scrolls fandom page. Okay, so our next step is to utilize this ID in our condition statement to execute calculator when this item “activated” or, “picked up”. Something else to know about this item, is that according to the same fandom page, it does not spawn until the player character reaches level 12 and can appear in some random chest. So, to get around these challenges, we utilized the power of the in-game command console to spawn the item at the player’s location. To do this on PC, we can load up Skyrim, on the start screen hit the tilde key (~) to spawn the console, type “coc riverwood” to quickly load a character in-game, hit the tilde key again, type “player.placeatme 4E4E6”, which is the value of Meridia’s Beacon we found from the fandom site.
Here, we need to find the baseID (different than that formID mentioned above) of the beacon item we spawn in game. Let’s look at the next piece of code to accomplish this:
Notice here we changed from HitEvent to ActivateEvent. We no longer needed the HitEvent and were able to remove it completely. We declared some new variables to help us with the logging process. We wanted to log who picked up what, and what is the baseID of that item. Now that our code has updated, we compile this new version, and ensure that the DLL is in the correct Skyrim directory. In the video below, we demonstrate spawning the beacon item, and getting the desired value from the logs. Milestone #2 is complete!
Now we can modify our code to include our local code execution of the calc.exe like before, but only when the specific BaseID item is “activated” / picked up. Again, we’ll stroll through the code:
In this third version of our little experiment, nothing changes until we encounter the ‘if’ condition statement. Here, we simply state that IF the item picked up by the player matches the ID we found in the log, then we should run the ‘calc.exe’ program. If any item other than this one is picked up, the game will continue to run as usual. Next, the code needs to be compiled and placed in the appropriate directory. Afterward, we enter the game and spawn the beacon item as we did before, using the following command in the console:“player.placeatme 4e4e6”
Below, we demo just that:
Milestone 3 is complete, now, for the next phase, getting shell 😊
In POC3, we triggered the condition statement when the player picked up an item, which worked perfectly when the item was spawned at our feet and picked up. However, this approach did not work when the item was transferred, such as when it moved from a barrel to the player’s inventory. If you are familiar with the item, you know it is initially spawns in a chest (container) and then transfers to the player’s inventory (container). Initially, we attempted to initiate our code when the beacon item was registered into the player’s inventory, but this approach failed to properly make it work. Instead, we were successful at implementing our code whenever the beacon was placed into or removed from a container, so moving forward with POC4 onward, we switched from “activation” event to the “container change” event.
We inserted the reverse shell code into our code, right where the calculator code was:
This proof of concept is a bit busier. Starting at the top, we have included some Windows APIs needed for our reverse shell. We assign some new variables, including our attacker IP, where we have a listener set up, and the port number. Within the “OurEventSink” class, we have switched from “ActivateEvent” to “ContainerChangedEvent” as discussed.
Moving on, we removed some of the variables we used for logging, as they are no longer needed. If you’ve done a reverse shell in C before, the rest probably looks quite familiar. Examples of these can be easily found; there’s nothing special about this specific reverse shell source code.
Again, we build, place the new file in the correct directory, and test in the game by spawning the in-game beacon item, and picking it up. Nice! We can connect to our shell whenever the beacon item registers a container change!
What kind of Sheogorath madness is this?! 😊 Milestone #4 is now complete.
But enough of this milk-drinker, single target netcat stuff, let’s get into some real Havoc! Now, please understand, we’re not exactly at the “Arch-Mage” rank of hacking, maaayyybe Scholer / Wizard-ish. So, we figured this challenge would be a great opportunity to delve in more as we work towards our Master-Wizard transformation. We decided on a C2 framework for our little project, installed and set it up.
After conjuring up a listener in our C2 of choice, we generated a Windows shell code payload. The output generated an encrypted bin file, which was not quite the shell code format we were expecting. Since we’re new to the world of C2 frameworks, we were uncertain about how to integrate this bin file into our existing project. First, we thought about modifying our C++ file to download and execute this bin file, but that seemed too much trouble to have to download yet another file and then figure out how to execute it. We really wanted everything to be included in a single, malicious DLL File. We were determined to deplete the last little bit of magic we had and defeat this challenge.
During our research, we discovered that we could use the ‘xxd’ tool to generate a hexdump output that could be used as a variable in our existing code. Ah-ha! By the nines, a blast of clairvoyance had illuminated our path toward achieving our current objective. This felt like a page from the buffer overflow methodology, just without the whole, crashing, debugger, pointer stuff. Let’s go through it.
Here, we have xxd take the contents of the bin file generated by our C2, and hexdump’d it to a txt file.
xxd -i demon.x64.bin > output.txtWe then can take the contents and place that into a variable compatible with our source code, as seen here:
Okay, this took a few different intervals to get right, but what’s happening here is that we’ve now included threading support, and libraries to support memory allocation. An instance of the class gets created, along with a detached thread. All of this is to ensure that the game doesn’t freeze up upon execution. We see a variable creatively named, “teststuff”, where our xxd output goes. After that, we allocate executable memory, copy the shell code into that space, and execute our fancy beacon code. We even clean up the allocated memory after the shell code has been executed. Admittedly, we were quite skeptical about the success of this process, but we’re just a couple ethical hackers doing research, right? So, let’s give it a shot and see what happens.
Finally, we built our code in the IDE, placed the new DLL in our mod folder, and tested it. Below, we set up three separate VM’s, and place the DLL in each. As we can see, as each player picks up the beacon item in game, we get three separate beacon call backs to our C2. Wizardry!
Hey, maybe now we can light up the Burning Man, and have our Master-Wizard ceremony at the Bard college, eh?
We know this idea can be taken further. Could you imagine being able to play Skyrim on a public server, with some lunatic running around Riverwood, placing bootleg, malicious Beacons in barrels for unsuspecting victims to pick up these items and spawn Beacons?
That could never happen… right?
Think of the possibilities with proper mod development. We’ve only demonstrated a simple container change to execute the callback, but what if it were a spell? Or special arrows? Imagine joining a server, and suddenly, a player hits you with such a spell or arrow, giving them access to your personal computer…
Thank you for joining us on this adventure! We have gained some very interesting insights during this tech write-up, and we absolutely love that we got to combine hacking and Skyrim to explore this incredible game from such a different perspective. We’re glad to have kept your interest this long, whether you’re a student, a Greybeard, or somewhere in between. We hope you truly enjoyed our first technical blog.
We’d like to reiterate that we are solely utilizing the capabilities provided by existing modding frameworks and have not altered the original software files. This article is intended solely to explore the risks associated with downloading software from untrusted sources. Be safe adventurers, we look forward to providing our next technical blog in the future.
Now that we’ve concluded this blog, we’re taking a break, jumping back onto our ship, and exploring more Starfield! Unmodded… of course 😊 🚀, and we close out with Bowser singing the Song of Beacons!:
