The LEAP project November 2021 Mark Fisher(SID 11707486), Lewis Ellard (SID 11218993), Prabhjit Lal(SID 11229357),

User guide: To run the programme, download all the modules and run the command to start a python programme on your terminal, followed by leap.py - eg

python3 leap.py Allowed options are leap.py, leap.py enumerate and leap.py privesc. If run from a Linux terminal, only valid Linux options will be displayed, and if run from Windows, only Windows options will be shown.

The menu should then guide you through the various enumeration and privilege escalation options available. You will have the option to display the output either to the terminal, or to a file of your choice. If you choose to output to a file, your current working directory will be displayed, as a reminder of where you are in your system.

The programme contains options for: Linux enumeration; show the running operating system show files running with SUID privileges display previous logins on the current system show hidden files

Linux privilege exploitation; SUID exploit using the 'find' command SSH Vulnerability - Read files which would otherwise need root privileges or use of sudo.

Windows enumeration; show the running services access tockens show the accounts on a windows system

Updates Lewis - working on SSH priviledge escalation Mark - working on enumerations (Windows and Linux display ARP table) & Linux SUID files; Linux SUID privesc; Task 3 + menu Mo - working on enumerations (network and port scanning) Ashraf - TBA Miles - TBA Prab - working on enumerations (Windows-Access Tockens & Linux-Hidden Files) and Task3

Hi, I've just tried to upload some more files for you to have a look at. Hope they're OK, let me know what you think. The privesc ones are about as good as I can get them for now, if you can see a way to improve them please feel free to have a go, or let me know. I've uploaded the output choice file I mentioned for you to have a look at as well - do you think it will be OK? I'll try to work on the basics of some more enumeration scripts over the next few days if that's OK with everyone

Hi Group, Dan's just shown me how we submit ideas to each other in this document, so I'll have a go. I think we need to work this way so Ian can mark it, not work via discord. Looking at the things Ian suggested in this document, I've written my suggestions below his ideas;

Will each piece of functionality be in a separate file or subdirectory? #Do you think seperate files would be easier?
Will your team have a naming convention? For example, maybe all windows enumerators will begin with "wEnum_", linux with "lEnum_" and so on. #I've been starting all my files with #l_mark_filename_ #(l for leap, followed by my name). Is that OK with everyone? How about #l_mark_windows_enum1 and #l_mark_linux_privesc1 #etc for those two main types of files?
What will each function return or display? Will each function print out to the user? Or will it return a block of text in a string? Or a list of lines? Or maybe a dict with some meta-info (version, plugin name, plugin author, date, time, etc.) and text data? Or JSON? All are possibilities. #My output is text at the moment, what are other peope doing?
Will you have a standard set of parameters to be passed in? Or can each plugin have a different set of required parameters? #I think it's easier to each keep to our own way at the moment, unless anybody can foresee problems
What plugins will be implemented? Who will be the author? #So far I've had a go at Linux enumeration and Windows enumeration, which I seem to be doing OK with. #(Suggestion - Have a look at pythons "platform" module if you haven't already.) #I've also looked at Linux privesc and Windows privesc, although I admit I'm struggling with that. I am working on a privesc which uses SUID which #looks promising, though I still need to try to unit test it and check it. Dan's just been a great help with showing me some unit testing, so I'll have a go. #When we've agreed on the points above and it seems OK, I'll get it uploaded. #I've also had a good go at letting the user choose output to go either to the terminal or to a file with the location and name of their choice, which is coming #on quite well - again, I just need to finalise it and thoroughly test it when we've agreed on the format.

#What do you think? Does anybody else have any suggestions, or can see anything wrong with my ideas? I haven't done anything which can't be changed, I've just been learning about the things I'm trying to do

#How is everybody else doing?

#Mark

LEAP

LEAP: Local Enumeration And Privesc. Framework for 4061CEM project.

TODO

Update Docs

What is here?

Not much.

This project requires you to generate most of the actual code yourselves. To start with, each team should work on a fork of this repository together to define the common features of the individual pieces of functionality - we'll refer to them as "plugins". This is a kind of design by contract, which you can read about here: https://www.sciencedirect.com/topics/computer-science/design-by-contract. Some things to decide might be:

Will each piece of functionality be in a separate file or subdirectory?
Will your team have a naming convention? For example, maybe all windows enumerators will begin with "wEnum_", linux with "lEnum_" and so on.
What will each function return or display? Will each function print out to the user? Or will it return a block of text in a string? Or a list of lines? Or maybe a dict with some meta-info (version, plugin name, plugin author, date, time, etc.) and text data? Or JSON? All are possibilities.
Will you have a standard set of parameters to be passed in? Or can each plugin have a different set of required parameters?
What plugins will be implemented? Who will be the author?

You should document these decisions here in the README.md file. Once you are all happy with this, stage, commit and push it to your shared fork. Then, each team member can begin writing their own tool by creating an individual fork or using branching. Naming your tool something sensible and uniquely identifiable at this point will be very helpful. If you all keep the simple name "LEAP", you will might it tricky to remember which repository you are working on later. You can call your own fork whatever you like.

When the individual tools are working and each team member has their own plugins working, it is their responsibility to liaise with the other members of the team to import the other plugins. Each team member should create a fork of the repositories of each of their team-mates, integrate their plugins and submit a pull-request for each fork. If using branches, then each team member can merge into their branch from either the master (if any system changes are made) or from other users' forks (to incorporate their plugins).

If using forks, with team members being A, B, C and D, they will have one fork to start with in which the team collaborates on defining the basics. Then A will create a personal fork of the shared repository and work on their tool and plugins. When they're done, they will create forks from their team-mate's repositories. Let's call them LEAP-B, LEAP-C and LEAP-D. A will then port their plugins to each of these new forks and submit pull requests for them to be merged into the repositories of their teammates.

Why?

This might seem overly complex, but it's not. In reality, this is one of the common ways people collaborate using git. You can fork any public project and work on your own copy without needing to ask permission or get added to the original repo, then if you want to recommend your changes to the original author you create a pull request and they can decide to merge it into their work or not.

In this project you will be getting experience of working on a project and receiving multiple pull-requests from contributors and at the same time, contributing to the repositories of others.

Your Submission

Key points for submission:

You should submit your work through Aula as a PDF.
We will be marking anonymously, so try not to identify yourself in the report. Use a pseudonym or redact any code or screenshots that includes your name.
In the information on the repository, provide a screenshot of the sequence of commits as well as a link to your final commit. You can find this information from the github.coventry.ac.uk web interface by clicking on the "X commits" button:
Do not use screenshots for code. You can format your code for Word using a tool such as the http://www.planetb.ca/syntax-highlight-word website
- And definitely do not take photographs of your screen in order to show code
Make sure you include ALL of the source code required for your submission in appendices. This includes the code imported from your group members.
But also make it clear which parts are not yours.
- The easiest method is to have a section showing just your code and the full code as an appendix.
Each person should have their own privesc and enumeration code as well as the privescs and enumerations of their group. You should not be developing these components as a group.
For the basic task, you can share the menu code or use the one provided, modified as required.
For the intermediate tasks onward, you should make your own modifications or alternative menu code. This means you can work on the same base as your group, but add your own modifications not shared with your group in order to achieve the later tasks.
If your group failed to work together, you can still show you incorporated the work of others. The phantom member branch of the master LEAP repository (https://github.coventry.ac.uk/CUEH/LEAP/tree/phantom_member) can be used as a source. Imagine this is the code of a member of your group and use the privesc and enumeration classes that it contains to add to your tool. You may need to make modifications, just as you might with members of your group, if you have diverged from the shared menu system. This is expected if you are attempting the intermediate or advanced tasks.

Suggested Report Outline

This is just a suggestion.

Introduction.

Explain the tool. What is it's purpose?

User documentation

How do we run this? How do we operate it?

Unit Tests

A table of the tests you created. Like last time: https://github.coventry.ac.uk/pages/CUEH/4061CEM/assessment/cw1/example.html#org1514c40

Plugins

What plugins did you create?
What plugins did your team members create?

Repository

A screenshot of your commits, demonstrating your sequence of development and where you incorporated group-members' code
A link to the repository

Appendix A: Your Code

This is the code that is yours. If you used code from other sources in this section, make clear which parts and where it came from. This includes things from web-pages and the code you were given in the master repo

Appendix B: All source code

Include all source code here, including that which comes from your team for plugins. Again, make sure to highlight the source of any code that is not yours. You can simply say that your team contributions are from "team members" in order to maintain anonymity.

ellardl2/LEAP

About

Resources

Stars

Watchers

Forks

Releases

Languages