Tool Creation “You’re gonna need a bigger rootkit” 

What kind of tools do we need? —  Some case studies (from real CTF teams) —  Exploit launchers —  (extremely) custom rootkits —  System defensive software —  Software tracers —  Stuff you can think of —  A shell to interact with your systems that hasn’t been compromised by an attacker 

Some case studies —  Exploit launching frameworks —  Remote control toolkits —  Defensive software 

Exploit launching framework —  Describe your exploits similar to how Metasploit does —  “This works on the Foo service running on port 8118” —  “It spawns a shell on port 12345” —  This framework knows how to address other teams and just keeps trying to own them —  Give this framework its own root kit —  This root kit has the ability to act as a proxy for the main framework —  Hilarity ensues 

Detour: only-in-memory programs —  What if you don’t write programs to the file system? —  Post-exploitation, your shell code: —  Downloads another, big, blob of code —  Fixes it up a little —  Executes it —  This blob can be written in C, so can be big and complicated —  However, it’ll never have a native linking format and will only run out of other processes address spaces —  Hermit crab? 

In-memory programs —  This reduces to some interesting systems programming problems to make a program that is: —  Position-independent —  Dynamically resolves all external functions —  Is otherwise a remote control program —  Meterpreter is, in some modes of operation, designed this way —  Metasploit shellcode downloads the meterpreter DLL and loads it into the exploited process —  Bonus: meterpreter is capable of migration into other processes —  Writing this type of system is a good systems programming rite of passage 

Custom rootkit case study —  Let’s say you go about being noisy and make a process —  How will another team stop you? —  Using kill  on your PID —  Thought: fork  changes PID —  What if I have a rootkit that constantly forks? —  How would you kill it? —  Spoiler alert: it’s really, really annoying (French team did this DEFCON 2012) 

Rootkit communications —  Bad: other guys system administrators see data from their file system in network dumps —  Solution: encrypt your communications —  Easier/harder than it sounds —  Roll your encryption into your position-independent memory-only payload —  Meterpreter also does this 

Case study: debugger —  Debug attach to all challenge programs —  Break on ‘open’ —  Your debugger considers if this call is valid or not —  If not, terminates process —  This stops lots and lots of post-exploitation payloads —  How would you adapt a post-exploitation payload to work with this? 

General infrastructure —  Communication is extremely important —  You’ll want some generic tools —  Probably some kind of private chat like IRC —  A local Etherpad instance is very useful —  An anonymous FTP or SMB share for sharing files —  Try and have a sense of who on your team is doing what at any given time – staying on IRC can help with this 

Conclusion —  Lots of little pieces of software to write —  Some of it you can only do when you see your game world or have some (very annoying) scenario to solve —  Others you can’t possibly write in time, so work on it ahead of time —  Be prepared