DerStarke

('toc' missing)

Future Ideas

Phase 1 of DSDirectorate of Support v1.3
Phase 2 of DSDirectorate of Support v1.3
Phase 3 of DSDirectorate of Support v1.3

1. Build Options
   1. Switch to the Python builder based on Aeris
   2. Change DarkMatter to allow payload changes and GUIDGlobally Unique Identifier changes without a complete rebuild. That "configuration" step would be accomplishable by an operator
   3. Allow the installer to be written to a FAT-formatted USBUniversal Serial Bus drive as /boot/EFI/bootx64.efi. That would potentially allow the "configurator" step to be performed on Linux.
   4. Make builder and configurator work on Linux
   5. Allow patching of Bokor so that different combinations of OSOperating System support may be configured by the operator. Maybe use seperate FFS files for each of the kernel implants?
   6. Modify TritonBuilder to not create ImplantInstaller for a DerStarke build... maybe add a preprocessor directive #ifdef DERSTARKE... or something like that.
   7. Separate the Payload Builder and the Configurator
   8. Add a hibernation period that is optionally used only when hibernation date is unspecified.????? What is the easiest way to do this?
2. Enhanced Beaconing
   1. Fix user-agent string when sending requests from beacon.
   2. Accept any HTTPHypertext Transfer Protocol responses < 400 (instead of requiring 2xx).
   3. Add a regular trigger based on time (not based on using a web browser), and add jitter. Maybe use mDNSResponder instead of a browser if no browser is in use?
   4. Can we open a Safari instance with no window and then connect to the Internet? We can do that with Internet Explorer on Windows fairly easily.
   5. Can we inject into Little Snitch? And what ports/hosts is Little Snitch allowed to access?
   6. Make the survey optional/as a bundle.
   7. Implement the "Common Command Set"
   8. Change "high-priority fetch" to "get"
   9. Add the ability to remotely configure the darkmatter NVRAMNon-volatile Random Access Memory variables.
   10. Add the ability to specify an array of tasks, to be executed sequentially.
   11. Add the ability to send a "Go Dormant and Hibernate" tasking to change the hibernation date so that it can go dormant after it starts.
3. Enhanced Capabilities
   1. Modify Bokor to support loading kexts that interface with IOKit.
   2. Idea for a tasking payload: Implant a user's iPhone that is connected to the computer (either physically via USBUniversal Serial Bus or wirelessly via over-the-air synching that was introduced in iOS 5)
   3. Test Bokor by loading a kext that has scattered relocations ('otool -r' will provide details about relocations).
   4. Calc statitistics for the latest used web browser and try that one first
   5. Can we "fake" an EFIExtensible Firmware Interface update so the user thinks the firmware update happened, but didn't actually. Maybe also change the firmware version number.
   6. Make the Triton component updatable without firmware modifications.
   7. Find/create a directory on the hard drive where Triton will assume all files are encrypted bundles.
   8. Integrate MagicBox crypto.
4. Obfuscation
   1. Definitely obfuscate strings in Loader.
      1. sysctl__hw_memsize
      2. GUIDs
      3. injection targets (diskarbitrationd)
   2. Removing "-g" from GCCGNU Compiler Collection build options in tools_def.txt seems to result in unrecognizable *.efi files...why?
   3. Obfuscate the Status and Config NVRAMNon-volatile Random Access Memory Var guid/names in Triton.
5. Enhanced Persistence
   1. Add support for new hardware (MBP9x, MBA5x, MBP10x)
   2. Fix the determination of warning_count in regards to a system booting Windows.
      • If a system booted Windows that should not be considered a failed injection. Some ideas are to examine boot.efi to see the last time OSXApple operating system booted.
   3. Identify the meaning of the first DWord in the zero-vector at the top of the firmware volume in the latest MBA firmware.
   4. Add a lock to PCH SPI FWH to not need to not have to deal with patching - AP
      • Would have to gain execution before the lock occurred
   5. Do an initial survey collection (as in Dark Mallet)
   6. Change the output format (from smileys) to something more intelligible (like SUCCESS or FAILURE with a 3-5 second sleep), and also provide an install receipt
   7. Make Thunderbolt driver that just loads VI from a connected SimpleFileSystem (to get around an EFIExtensible Firmware Interface password that prevents booting from USBUniversal Serial Bus drive).
   8. Productize persistence across firmware updates.
   9. Investigate Windows kernel injection at boot time.
   10. Detect EFIExtensible Firmware Interface compression scheme and use the appropriate compression algorithm.
   11. Find the threshold of when NVRAMNon-volatile Random Access Memory gets flushed... will help how to solve storing Triton config
   12. Compress kernel and user-space payloads before encrypting (and then have loader decompress them at runtime). This should dramatically reduce the size of Loader.
   13. Can we move the Uninstall code to actually execute during a Virtual Memory callback? This would make it look like the OSOperating System has already started booting.... and may help with the black screen problem on the 13" MBP8,1.
6. Post-Processing
   1. Support export into CCDF format
   2. Allow multiple versions of the same file to be presented after post-processing (i.e. Use the path and modified date for unique identifiers)

1. Done
   1. If an exfil is still on-going at beacon time, then send a response that the implant is still alive and is still working on an exfil. If the new tasking is high-priority, then stop the current exfil and start the high-priority exfil.
      
      

DerStarke Jenkins Automated Build Process

• The Jenkins Build server is located at: http://10.2.0.107:8080/
• DerStarke Job is at: http://10.2.0.107:8080/job/DerStarke/
  
  

Creating new Unlock files future firmwares

1. Grab trunk of darkmatter and navigate to in/unlock dir
2. Use SFIT to extract the PchSpiRuntime file (this file locks FVH through the PCH)
   • Use the following command to parse the new firmware to find out which file is the PchSpiRuntime
     • python3 -m sfit <firmware file>
   • Locate the PchSpiRuntime file (GUID: c194c6ea-b68c-4981-b64b-9bd271474b20)
   • Extract the depex and efi files with the following command:
     • python3 -m sfit <firmware file> <depex file id from prev listing> <output filename>
     • python3 -m sfit <firmware file> <PE32 file id from prev listing> <output filename>
   • Copy the depex and efi files to in/unlock/extracted
3. Use Ghidra to find where to subvert flash locking code
   • Find the FlashLockingCode function
     • Use previous version of an RE'd firmware for guidance
     • The function should have the following flow (or similar)
       1. Get the EfiHobList
       2. Iterate through to find the value of BootMode
       3. If BootMode == 0x12 or BootMode == 0x20 keep the flash unlocked... else lock the flash
   • Patch the FlashLocking Code in order to always keep the flash unlocked
     • General idea is that there is usually a local variable that is also being check (default name of cVar1 by Ghidra)
     • If the variable == 0, the code will flow in the same direction of not locking the flash
     • The variable is initialized to 0, and only assigned a value in one spot.
     • Find that MOV statement, and NOP the 2-3 bytes of that instruction (NOP is 0x90)
     • Make modicications in a hex editor, and reload into Ghirda to make sure it has the desired disassembly and flow
       • I have had zero luck making the changes inside Ghidra and using the export wizard
     • Save the file in in/unlock
4. Generate Dxe File from Efi using create_unlock.py
   1. Open create_unlock.py inside the in/
   2. Find the definition of PchSpiRuntimeFiles structure (~line number22)
   3. Add a new entry for the new PchSpiRuntime file
      • Elements are [filename of patched file done in step 3, extracted depex from step 2, output dxe with standard compression, output dxe with lama compression]
   4. Run the python file and you should have both a standard and lama compressed Unlock file
5. Integrate new file into DarkMatter source
   • For Makefile
     1. Add exports to point to respective .h files (MBXXX_UNLOCK_H and MBXXX_UNLOAD_LZMA_H)
     2. Add exports to point to respective .dxe files (MBXXX_UNLOCK_DXE and MBXXX_UNLOAD_LZMA_DXE)
     3. Add new .h to dependence to flash_unlock_files
     4. Add rule to create .h files (MBXXX_UNLOCK_H)
   • For Loader.c
     1. Add #include for both .h files (std and lzma)
     2. Add new enum type MacModelNames
     3. Add new ImplantStruct PatchedFiles (make sure they align, ie, MacModelNames MBP_61 is the 0th element of PatchFiles)
     4. Add if case inside function PatchFirmware()
        
        

Compiling UDK BaseTools for Linux

1. Copy UDK/BaseTools/Source to Linux destination
2. Add -static flag to Source/C/Makefiles/app.makefile:
   • $(LINKER) -static -o $(APPLICATION) $(LFLAGS) $(OBJECTS) -L$(MAKEROOT)/libs $(LIBS)
3. Only need to build the following binaries for DerStarkeBuilder:
   1. GenSec
   2. GenFfs
   3. LzmaCompress (Standard compress is built into GenSec)
4. If Linux distro does not have uuid lib, remove it from any GNUmakefile (UDK doesn't actually use it):
   • Example: Source/C/GenSec/GNUmakefile
5. make clean && make at Source/C path... output at Source/C/bin