Disclaimer: All activity on this blog post are on my own personal time, my own personal devices and of my own personal opinion and do not represent that of my employers.
It’s no secret by now that the studio behind Cyberpunk 2077 fell victim to a targeted cyber attack. If you comb through the articles below, you can make some educated guesses that the attacker either got access to a file-share with game source-code, compiled build items etc. or got access to the source control system that houses the source code altogether. It’s all speculation at this point and I personally have no way to know but it did get me thinking more theoretically …
Given the breach history, I started to play Cyberpunk 2077 on an x-box in my lab away from my corporate and personal devices. After 5 hours of gameplay, I experienced a complete system crash. Certainly, this could be overheating, but oddly I did not experience a “ventilation error”. Instead, I experienced a failure of the video output first, then the audio output (screeching noise), followed by a system shut-down.
Following the crash, the days I would leave Cyberpunk 2077 running, I would experience new bugs in the x-box GUI interface. Strange behavior, such as “static” in front of the pictures, “the screen turning green” and the GUI elements moving from side to side and across the monitor …. this could be complete coincidence but needless to say it did have curious whether the cyberpunk 2077 software was compromised in some way. A far stretch that game softwaree would crash the entire device given the use of hyper-v to isolate applications and runtime environments …. but it’s fun to tinker with toys and poke around sometimes.
The above example, illustrates a very “simple” version of what could happen to the supply chain during software development cycle. This is nothing new to an experienced software engineer, yet we still see global scale supply chain software attacks such as SolarWinds. This is because commonly software is built on many other software dependencies and packages creating a complex web of interdependencies of software pointing to software pointing to more software. You get it… The complex nature of code dependencies and millions of line of code makes “visually” seeing malicious code really hard for humans.
More over, because code can be written in may ways and often “obfuscated” simply writing programs to “scan” code doesn’t always work … such as the case of traditional AV and source code analysis. It’s not really until you run the code that you can observe the behavior of the processes, the children processes, application service accounts, memory management, kernel calls and network behavior to determine if something looks “weird” or “strange” ….
I own a commercial xbox and it would technically be illegal to open and modify the hardware and software to inspect the memory and runtime because I do not have license for a x-box GameKit but I did decide to observe my own local network traffic using my Intrusion Detection Systems, Packet Capture system and Firewall Logs….
Essentially, the PoC looked like this …
x-box —> [Inspection Device | Firewall ] –> DMZ — RouterFW–> Internet
Packet capture / FW logs / Flow logs
I set my network device interface in “promiscuous mode enabled” / “pcap enabled” mode allowed the internet egress out the firewall on both the LAN and WAN interface… specifically I allowed the firewall to “PASS” traffic on purpose … expecting to see typically x-box communications
Afterwards, I let the CyberPunk 2077 play in the background for around 20 minutes. I could not afford to let this play in the background for hour long sessions due to the potential storage impact on my local lab network device. Then I dumped the PCAPs onto my local lab machine for the typical manual WireShark analysis….
Secondly, I put the firewall in DENY egress to the internet. Essentially any x-box / game network protocol communication should be blocked showing attempted connections in the firewall logs with a pfblockerNG FW reverse IP DNS lookup to capture the domain to IP where possible. These logs may also indicate failed attempts to a command and control server from malicious code running on my x-box. I did this for an additional 30 minutes of game play and game running in the background.
Thirdly, I ensured my suricata rules engine was listening in “in-line” mode for common network signatures of indicators of compromise. For example, if attempts to form a reverse shell to a command and control server or stuff UDP frames with data exfiltrations… it would possible catch it…
With only an hour of different tests running, my devices did not experience any unusual DNS resolution, IP connection attempts or in-line network security signatures that would indicate malicious code attempting to communicate back out of my network from the CyberPunk 2077 binaries.
Of course, in reality this test should run for 24 hours or longer, with far more gameplay and code execution events and have far more data to truly understand the client’s behavior. The bugs in my xbox could be unrelated to CyberPunk but I personally doubt it, because nothing on-the machine has changed except the CyberPunk install. Even though I didn’t find anything unusual during this Saturday side project, I personally uninstalled the game software and haven’t seen the GUI bugs present themselves again (weird). It’s just not worth it for me to burn up a $400 game console …