Summit Route End Point Protection (SREPP) code dump


RSS feed

The original purpose of Summit Route was to create a company that would sell a service to monitor and protect systems by recording and potentially blocking new processes from starting. The basic problem I was trying to solve was to block users from downloading and executing random executables, and make it more friendly to admins or security teams than AppLocker. From there the product would expand to a variety of other end-point problems. Things didn’t work out business-wise, I never brought the product to market, and I’ve been doing something completely different for about a year now.

I’ve been asked a lot why I haven’t open-sourced it. Quite simply it’s because it’d just be a code dump, that I don’t want to maintain or support and that never progressed to a fully functional product. But people keep asking, so here it is: the client and the server.

Although this never progressed beyond a proof-of-concept phase, it’s quite a complete architecture and no known bugs other than lacking lots of functionality. It shouldn’t ever blue screen. The main capability missing is the ability to create rules of what to block. The software is capable of blocking things, but it has no rule engine or rules to abide by, so as it exists, this is really just code for something like Sysmon, with centralized collection of every unique executable run, and a web UI to inspect some of the data.

Executable filtering

Figure 1

The Client

The client code is all the code that runs on the end-points. It consists of an agent written in C# that runs as a system service and communicates with the server that would run on Amazon AWS. The agent communicates with a C# UI process in order to inform the user when something has been blocked. The agent also calls into a C DLL that communicates with a C kernel driver that is responsible for intercepting new process execution attempts.


The Server

The server code all runs on AWS, or can be run locally on a Debian server. This includes a Golang web server that agents communicate with, resulting in files being written, data being written to a Postgres DB or receiving tasking from the DB, and potentially new jobs being created for a RabbitMQ server. Python workers perform the jobs created. A second Golang web server allows admins to see the data in the database. The frontend for that server is ReactJS.


What now?

This is just a code dump, that I won’t be maintaining. It’s not really useful, but hopefully if someone is looking to do something similar this will jumpstart a lot of what they would need to do. Taking this to the level where you could actually have customers would still be months of work, including:

  • The rules engine and ability to create rules
  • Web UI work to give better access to the data
  • Testing: There are no unit tests anywhere.
  • Security: Rate limiting of password resets and auditing of things. Change KeyForObfuscation, YOUR_SECRET_FOR_TOKEN, and any other security values.
  • Analysis of data: Give customers some understanding of what is known good, tie into VirusTotal for known bads, etc.
  • Clean up TODO’s everywhere in code.