When I first released Sheepl 0.1 in September 2018 as part of a talk, I wanted to showcase a different approach to user emulation, and the initial idea was well received. Security and IT professionals could see the potential and I had always believed that this tool could make a solid contribution to critical training aspects of information security. The benefits of replicating users within a network environment are obvious and people have since contacted me about their intentions to create Sheepl for use in various types of environments. Other use case ideas came to light, for example testing SIEM effectiveness by creating trails of activity on an endpoint that would later be captured forensically for examination, requiring a reconstruction of events mirroring how a real-world incident response would proceed.
Sheepl 0.2 was a simple enhancement and I used Sheepl to add some keylogging functionality to a cyber range I was involved in. Due to the tools ability to break predictability, when the first entries for a successful key logging capture appeared, we responded with an urgency that replicated any credential capture in the field.
The more I used the tool, the more I realised I was unhappy with the current structures. Remembering all the places to create code edits was annoying and what should have been a simple process was error prone if you forgot to add in another ‘if/else’. What was initially a proof of concept didn’t support expansion towards the direction and capabilities I envisaged for the tool. Adding new tasks was cumbersome. The existing approach to adding command line options for each task didn’t scale when you consider I wanted to add 100’s of tasks.
So after careful review of the current situation, I decided that my best course of action would be to build this on solid foundations and therefore rewrite and reorganise the code base. Rather than incremental releases of the original project, I opted for the next logical release version which to my mind compliments the new features, approaches, and capabilities within the tool. Sheepl 2.0 is the culmination of that work and is 10 times more powerful creating highly realistic and unpredictable security testing environments.
Key Sheepl 2.0 Features Include:
Each task is now a fully encapsulated class that is associated with a new Sheepl object. Each task now also has its own extensible CMD module which means that when working in interactive mode, task specific requirements can be easily added. Word document tasks need input files with text to type out whereas Remote Desktop connections require connection credentials. Another example of task specific requirement is the ability to specify a command file containing commands one per line where this would be relevant, i.e. ‘CommandShell’, ‘PowerShell’ and ‘PuttyConnection’ tasks. This is all handled within the respective class whilst inheriting common menu functionality from a parent command line.
Tasks now have a specific naming convention, camel case, and this change means that it is possible to programmatically import classes as needed which is more memory efficient. There is no point in importing 100 modules if you only intend to use 2.
It also means that you no longer need to edit the core as Sheepl will automatically populate the available tasks based on the task Class names, removing the need for any manual declaration.
Adding the ability to get up and running with the basis of a new task seemed useful and I have built this directly into the tool. I have also introduced the concept of categories of tasks by utilising the folder structures, which can be expanded on in the future to correlate tasks to specific types such as network actions, office interaction etc. You can use the template switch to specify a new template name in a category and the stub code for this task will be created with all the correct inheritance in place leaving you to focus on the interactivity required to complete the task.
Using Argparse as the number of tasks grew was not a manageable solution moving forward so an alternative way of programmatically creating Sheepl without interaction was needed. This is realised in the form of JSON profiles and the new profiles option. You can now define Sheepl within a JSON template specifying core traits such as typing speed and duration, together with all the requirements needed to assign tasks creating realistic scenarios.
When assigning a task such as Remote Desktop, it is useful to think beyond the initial opportunities to keylog credentials as Sheepl types out the connection requirements. In the real world, users connect to other servers to perform actions. You can already achieve this using PowerShell tasks and WinRM, but if the interaction is outside of a command shell, then it becomes complicated. Subtasks aim to solve that problem.
When authoring a new task for Sheepl to perform, you have the option in the code to specify whether subtasking is supported, as in the case of Remote Desktop connections. The great thing about this is that all the tasks become potentially available to be used within the remote connection. As an example, you could create a Sheepl that created a Remote Desktop connection, then performed some command shell activity, used Putty to make a remote connection to a Linux SSH server and then disconnected. This is achieved because tasks are modular so can be implemented into local or remote connections. The only caveat is that if you want to use specific program interactivity, that program needs to be available remotely. Thinking creatively, you could always chain tasks together to get Sheepl to install that program for you. Subtasking opens even more possibilities for user emulation.
Working on this project has been rewarding and the positive feedback it has received is great. Now that the structure of Sheepl 2.0 is in place there are opportunities to use it in many ways. Whilst its first inception was to support realistic lab application and therefore to support a more realistic learning experience, it has transpired that there are applications beyond this. Sheepl provides an effective way to execute a sequence of tasks and commands on a Windows system and as a by-product of this capability offers ways to test and evaluate products that are designed to detect and alert against certain types of user behaviour. The focus of the tool will continue to be on tradecraft development but with version 2.0, the applications for developing this tradecraft now extend beyond the lab environment.
Sheepl 2.0 along with supporting materials and video are available on GitHub at: https://www.github.com/SpiderLabs/sheepl