Mr. Robot Disassembled: eps3.2_legacy.so
Hello friend. I’m Ryan Kazanciyan, Technical Consultant for Mr. Robot and Chief Security Architect for Tanium. I’ve been working with Kor Adana — Writer, Producer, and mastermind behind the ARG — and the rest of the Mr. Robot team since the second half of Season 2. Throughout Season 3, I’ll be writing about the hacks depicted in the show, how they came together, and their basis in reality.
Spoiler Alert! This post discusses events from the third episode of Season 3.
After last week’s breakneck pace of hacks, “eps3.2_legacy.so” offers a bit of a breather — and a chance to finally see what happened to Tyrell after Five/Nine. This episode featured several scenes with hacking tools and source code that all connect back to events from past season. As a result, Kor and I had to be particularly mindful of continuity, ensuring that every tool and line of output matched up with on-screen details in preceding episodes.
Crafting the Five/Nine attack
“eps3.2_legacy.so” opens with the pivotal moment in which Elliot / Mr. Robot and Tyrell launch the Five/Nine attack. Back in episode 201, we got a brief look at the start of the encryption process as it ran on a victim host in the E Corp network.
In this episode, we had to show the attack underway when Tyrell returns to the terminal several minutes later. Kor and I wanted to make it clear that the process was infecting and encrypting thousands of E Corp systems, not just one host at a time. We also wanted to avoid designing the stereotypical “progress bar of doom” that is featured in so many hacking scenes in film and TV.
I decided that the Five/Nine malware would have several features that allowed it to rapidly propagate through the E Corp network. Each infected system would spawn threads that independently scanned subnets for online systems, then use previously-stolen credentials or other means to transfer and execute the payload using Secure Copy Protocol (SCP). This would ensure that the malware spread as quickly as possible.
This is fairly similar to how the NotPetya and Bad Rabbit ransomware spreads. Both exclusively target Windows hosts, so there are some implementation differences. They use code derived from Mimikatz to steal credentials from initially infected victims, and native Windows SMB and WMI to transfer and execute the malware to other systems. These types of attacks can inflict massive damage: shipping giant Maersk reported that NotPetya cost them over $300 million dollars.
With that design in mind, I mocked-up the output of this ongoing infection and propagation process — what you see on screen — to be as informative as possible so that a wider audience could follow along. That meant including lots of verbose status messages. Each thread prints an on-screen update indicating what it’s doing: scanning for new hosts, reporting how many are online, and proceeding with the file transfer and payload execution.
Since each thread runs asynchronously and may take a different duration of time to complete, the update messages are not in numeric order. During pauses with no activity, the script periodically reports “Waiting on thread updates…”
Last season’s femtocell attack had a ton of moving parts, from Elliot writing Android exploit code in S2E05, through Angela and Darlene working together to plant the device on E Corp’s network in S2E06. (I can’t take credit for these awesome sequences — that was all Kor and some of the show’s previous consultants). It also presented a mystery: what did the Dark Army do with the femtocell device before handing it back to Cisco and fsociety?
In “eps3.2_legacy.so”, we see Tyrell working in vim to complete the source code for
EnableAttack . This is the same tool that Angela runs on the femtocell device in S2E06, using the syntax:
./EnableAttack femtopwn WLAN0,WLAN1. This command brings up the cellular and wifi interfaces on the device, enables the femtocell payload to compromise the FBI’s Android phones, and provides the Dark Army with remote access to E Corp’s internal network.
Any time we include a shot that includes source code, I always want to ensure it’s syntactically valid and holds up to scrutiny, even if you only see part of the file. If we’re showing a custom tool, I have to write our own functional code. In this case, I also had to ensure that it produced the same output, and in the same logical order, as shown in prior episodes.
The manner in which Angela executes
./EnableAttack , and its lack of file extension, implies that it might be a native Linux binary. However, I decided that it’d make more sense for this to be implemented as a shell script that acts as a management and configuration wrapper. (In *nix, as long as a file has the executable bit set you can directly execute it, regardless of extension).
EnableAttack parses the command-line arguments and executes a sequence of other helper scripts and tools that carry out each step of the femtocell start-up process. To make my production work a bit easier, and to ensure that a wider audience can follow along, the script is filled with liberal use of comments and
echo statements. Tyrell is a meticulous developer who writes well-documented code.
When we get to see Tyrell’s screen, the script is almost complete and nearly identical to the mock-up above. He’s in the process of setting a configuration variable
implant_callback_addr to a domain name under the Dark Army’s control. Later parts of the script would presumably implement the call-back functionality that connects back to this C2 address, thereby giving the operator a foothold into E Corp’s network.
You’ll note that we use different C2 addresses and domains throughout scenes that feature the Dark Army’s backdoors. Sophisticated threat groups often diversify their C2 infrastructure, allowing them to use a different call-back domain or IP for each victim host. As they burrow their way into the E Corp environment and infect additional systems, you’d expect that they would deliberately avoid re-using the same C2 addresses. This provides resilience: if one address goes down or is discovered and blocked, the rest can remain functional.
Later in the scene, Tyrell stumbles across the Android exploit code that Elliot wrote in S2E05, and angrily questions why it’s there — he doesn’t know the full plan.
As many astute viewers picked up last year, this is based on a Samsung Knox exploit that’s written in Ruby and included in the Metasploit framework. We re-used the same source code to keep this shot consistent.