"Cymmetria’s MazeRunner platform lets you dominate an attacker’s movements from the very beginning and lead them to a monitored deception network."

Let me start off by saying that this is a wicked cool product!  It was really well thought out and it shows when you're bolting on each of the pieces to build your puzzle maze.  Despite this being the community version, it is very functional and gives you a really good idea as to how it can help protect your network.

The community version comes as an OVA.  After you spin it up, you are presented with the login page:





Upon logging in, we need to perform some setup steps:





Be patient while it runs the diagnostics...





When the diagnostics are finished and you're looking at all green check marks, select Launch MazeRunner:

 




We agree to the Terms:





And we're dropped into the main screen. 

We have a few options but the logical place to start is with a "Story" which is essentially a predefined decoy.  I choose SMB with SSH:





We have a few options to configure for our decoy:





Some options for our share:





And finally, we finish:





There are two methods for deploying our decoy.  We can run a virtual machine under the parent virtual machine (nested) or we can run it in standalone.  Not all hypervisors support this functionality and in my test, I'm using Xenserver.  While Xenserver "technically" supports nested virtual machines, in practice, it's hit or miss.  In this specific scenario, it was a miss.  Whenever I'd spin up the decoy, the parent VM would crash.  I moved to the standalone model which I actually prefer.  Maybe in a large scale situation, this wouldn't be ideal.  In my case, manually spinning up a few decoys is not a problem.

When the decoy is finished, we choose download to get the OVA for manual deployment:




The download size seems relatively the same across the few decoys I produced:





Note above the Status is "Not seen yet" which is sort of obvious considering that it's still downloading.  But once we get it spun up, moments later, the Status changes to "Active".





In a large environment, someone might actually man the console but in smaller environments, email alerts might be the best method for notification.  It was by chance that the default setting limits the number of alerts.  Lucky for me since a port scan of all 65,535 ports yielded an equal amount of alerts to the system.  





With everything setup, we move back to the Dashboard and we see our lonely decoy:





Learning from my first mistake, I choose to scan just the SSH port:





Moments later in our console, we see the alerts:





Back on our Dashboard, we see the notification for unresolved events:





Using SMBClient, I attempt to access the share:





We see our decoy share name. 

In my previous decoy setup, I didn't stick with the stock share, I actually created a new share and I was able to access it.  On the default, either through my lack of attention to detail or by design, the share is only visible but inaccessible.  No matter, the simplicity at which parameters can be changed on the fly is quite remarkable.  We edit our service:





We change the share name and we add a zip file.  Back in the console, we see the wheels turning:





When it finishes, we access the decoy with SMBClient:





We see our newly created share.  

As always, I move in parallel -- in another window, I'm running Enum4Linux:





We enumerate users:





With the little playing around I've done, the users above and below are tells.





That is to say that I noticed these are stock users and the three together would clue me in as an attacker as to what I stepped in. 

"ingthisleter" is listed on github as a "common username" but I couldn't quite figure out the origin.  Regardless, I didn't see a way to exclude the default users and that would be a must have to avoid tipping our hand.

In all fairness, this is my birdseye view look at this product and a deeper dive might educate me a little more as to ins and outs.

Moving back to SMB:





With our newly configured share, we are able to access Public with the Guest account.  Immediately after:





We get a different kind of alert.  Since we've actually touched the decoy on the inside, the type of alert changes and we also get an email notification:





On the Dashboard, we can drill into it:





On the Investigation screen, we can get into the specifics:





On a specific event, we can drill down deeper:





Wondering about other possibilities, I deploy a new service:





Like previously, it adds the changes to the live decoy and moments later, we are able to access the fake web service:





When we access the secrets.txt file:





Back in the console, another alert appears:





Back to the SMB Share, I add credentials to the share:





When we access the share using the credentials:





We see the specific details in the Investigation screen:





And because this alert is email worthy:





There is a ton more functionality to this product.  One of the cooler features is the ability to tie this into an Active Directory.  From there, we can deploy breadcrumbs to live systems (endpoints).  Think of these breadcrumbs are tripwires that come in various forms like documents, credentials, SSH keys, etc.  With breadcrumbs specifically, I might have confused there purpose initially as I was deploying breadcrumbs on decoys.  I don't think that is there actual design purpose.  

That is the 50 cent tour and just based on what I've seen so far, this product is impressive.  As an attacker, minus the one tell that I've already pointed out, I wouldn't know this decoy machine from an actual target.