How to Study Cyber SOC at home in 2023

How to Study Cyber SOC at home in 2023

  March 29, 2023    Davinder

---

Below is the complete guide to help you study cyber SOC at home.

Lets install SIEM First:

 There are various SIEM in the market like: QRadar, Graylog, ELK, Splunk, SumoLogic etc but we will example of Q RADAR

Download >https://lnkd.in/d7ATK9ND
install >https://lnkd.in/dWe7gZ7f

All material you need:- 

•  WinCollect Agent: https://bit.ly/3xhioeb
• 730_QRadar_wincollectupdate-7.3.1-16.sfs: https://bit.ly/3xdPzPS
• WinSCP-5.21.3-Setup: https://bit.ly/3QsblpO
• CCNA Cyber Ops SECOPS: https://bit.ly/3L0W6Dj
•  DSM Configuration Guide: https://ibm.co/3dhP9Bl
•  Incident Handling and Response: https://bit.ly/3QPvDtJ
•  What is SIEM: https://bit.ly/3dkIohW

If you encounter any of these issues below, I've collected the solutions.

. install WinCollect Agent another way:
https://lnkd.in/dA34UhEV |
https://lnkd.in/db_7ai_j

. send Linux logs to Qradar
https://lnkd.in/dnc6HYw9

. No Log Activity | Qradar CE 
https://lnkd.in/dTa2kFrM

. No Log Activity | Qradar Code:
https://lnkd.in/d3ZSVzx3

. Logs source problem:
https://bit.ly/3QyysPD

. Modify maximum Log size using Group Policy
https://lnkd.in/dmD7jqGK


. Rule creation, use case creation Basic in Qradar SIEM
https://lnkd.in/daWJmTu3 |
https://ibm.co/3DwndEq

✔️ Don't forget to generate an Authentication token from AS to write in WinCollect Agent when you install it

✔️ where logs and events from Windows, Linux, DB,..,etc :
 . DSM Configuration Guide: https://ibm.co/3dhP9Bl
Does it work? Great! That is a mini SOC. Document it somewhere and link it to your resume.🙏


------> Additional steps: <------

- Increase log visibility (activate PowerShell logging, Scriptblock logging, install Sysmon, etc)

- Install extra tools to get more visibility e.g.: Bluespan, DeepBlueCLI, Suricata Zeek, RITA (all are on GitHub)

- Test your setting! Be a bad guy and try to catch yourself. (WinPwn, Atomic Red Team, Caldera -> again, check out GitHub)

- If needed improve your SIEM with matching alert rules and build Dashboards. (Ideas? Look at Sigma rules -> GitHub)

Read More

Code Review Methods - Bug Hunting

Code Review Methods - Bug Hunting

  November 02, 2022    Davinder

---

We can find lot of web application level vulnerabilities by reviewing the code. Below are some of the steps that can help you discover these kind of bugs.

1.Important functions first

When reading source code, focus on important functions such as authentication, password reset, state-changing actions and sensitive info reads. (What is the most important would depend on the application.) Then, review how these components interact with other functionality. Finally, audit other less sensitive parts of the application.

2.Follow user input

Another approach is to follow the code that processes user input. User input such as HTTP request parameters, HTTP headers, HTTP request paths, database entries, file reads, and file uploads provide the entry points for attackers to exploit the application’s vulnerabilities.This may also help us to find some critical vulnerabilities like xxe,xxs,sql injection

3.Hardcoded secrets and credentials:

Hardcoded secrets such as API keys, encryption keys and database passwords can be easily discovered during a source code review. You can grep for keywords such as “key”, “secret”, “password”, “encrypt” or regex search for hex or base64 strings (depending on the key format in use).

4.Use of dangerous functions and outdated dependencies:

Unchecked use of dangerous functions and outdated dependencies are a huge source of bugs. Grep for specific functions for the language you are using and search through the dependency versions list to see if they are outdated.

5.Developer comments, hidden debug functionalities, configuration files, and the .git directory:

These are things that developers often forget about and they leave the application in a dangerous state. Developer comments can point out obvious programming mistakes, hidden debug functionalities often lead to privilege escalation, config files allow attackers to gather more information about your infrastructure and finally, an exposed .git directory allows attackers to reconstruct your source code.

6.Hidden paths, deprecated endpoints, and endpoints in development:

These are endpoints that users might not encounter when using the application normally. But if they work and they are discovered by an attacker, it can lead to vulnerabilities such as authentication bypass and sensitive information leak, depending on the exposed endpoint.

7.Weak cryptography or hashing algorithms:

This is an issue that is hard to find during a black-box test, but easy to spot when reviewing source code. Look for issues such as weak encryption keys, breakable encryption algorithms, and weak hashing algorithms. Grep for terms like ECB, MD4, and MD5.

8.Missing security checks on user input and regex strength:

Reviewing source code is a great way to find out what kind of security checks are missing. Read through the application’s documentation and test all the edge cases that you can think of. A great resource for what kind of edge cases that you should consider is PayloadsAllTheThings.(github)

9.Missing cookie flags:

Look out for missing cookie flags such as httpOnly and secure.

10.Unexpected behavior, conditionals, unnecessarily complex and verbose functions:

Additionally, pay special attention to the application’s unexpected behavior, conditionals, and complex functions. These locations are where obscure bugs are often discovered.

Read More

Account Takeover Methods

Account Takeover Methods

  November 02, 2022    Davinder

---

Chaining Session Hijacking with XSS

1.I have added a session hijacking method in broken authentication and session management.
2.If you find that on target.
3.Try anyway to steal cookies on that target.
4.Here I am saying look for xss .
5.If you find xss you can steal the cookies of victim and using session hijacking you can takeover the account of victim.

No Rate Limit On Login With Weak Password Policy

Password Reset Poisioning Leads To Token Theft
1.Go to password reset funtion.
2.Enter email and intercept the request.
3.Change host header to some other host i.e,
    Host:target.com
    Host:attacker.com
  also try to add some headers without changing host like
    X-Forwarded-Host: evil.com
    Referrer: https://evil.com
4.Forward this if you find that in next request attacker.com means you managed to successfully steal the token. :)

Using Auth Bypass

Check out Auth Bypass method, there is a method for OTP bypass via response manipulation, this can leads to account takeovers.
1.Enter the wrong auth code / Password
2.Capture a auth request in burpsuite and send it to repeater
3.Check for the resoponse
4.Change the respone by manipulating the following parameters
  {“code”:”invalid_credentials”} -> {“code”:”valid_credentials”}
  {“verify”:”false”}             -> {“verify”:”true”}
 
 

Try For CSRF On

1.Change Password function.
2.Email change
3.Change Security Question
Token Leaks In Response
So there are multiple ways to do it but all are same.

Token Leaks in Response

Steps(For Registration):

  1. For registeration intercept the signup request that contains the data you have entered.
  2. Click on action -> do -> intercept the response to this request.
  3. Click forward.
  4. Check response if that contains any link, any token or OTP.

Steps (For password reset):

 1. Intercept the forget password option.
 2. Click on action -> do -> intercept the response to this request.
 3. Click forward.
 4. Check response if that contains any link,any token or OTP.

Read More

What is an SSRF?

What is an SSRF?

  October 11, 2022    Davinder

---

SSRF stands for Server-Side Request Forgery. It's a vulnerability that allows a malicious user to cause the webserver to make an additional or edited HTTP request to the resource of the attacker's choosing.

Types of SSRF

There are two types of SSRF vulnerability; the first is a regular SSRF where data is returned to the attacker's screen. The second is a Blind SSRF vulnerability where an SSRF occurs, but no information is returned to the attacker's screen.

What's the impact?

A successful SSRF attack can result in any of the following: 

• Access to unauthorised areas.
• Access to customer/organisational data.
• Ability to Scale to internal networks.
• Reveal authentication tokens/credentials.

 

Potential SSRF vulnerabilities can be spotted in web applications in many different ways. Here is an example of four common places to look:

When a full URL is used in a parameter in the address bar:

A hidden field in a form:

A partial URL such as just the hostname:

Or perhaps only the path of the URL:

Some of these examples are easier to exploit than others, and this is where a lot of trial and error will be required to find a working payload.

If working with a blind SSRF where no output is reflected back to you, you'll need to use an external HTTP logging tool to monitor requests such as requestbin.com, your own HTTP server or Burp Suite's Collaborator client.

 

Read More

Path Traversal Vulnerability?

Path Traversal Vulnerability?

  October 06, 2022    Davinder

---

Also known as Directory traversal, a web security vulnerability allows an attacker to read operating system resources, such as local files on the server running an application. The attacker exploits this vulnerability by manipulating and abusing the web application's URL to locate and access files or directories stored outside the application's root directory.

Path traversal vulnerabilities occur when the user's input is passed to a function such as file_get_contents in PHP. It's important to note that the function is not the main contributor to the vulnerability. Often poor input validation or filtering is the cause of the vulnerability
In PHP, you can use the file_get_contents to read the content of a file. You can find more information about the function here.

We can test out the URL parameter by adding payloads to see how the web application behaves. Path traversal attacks, also known as the dot-dot-slash attack, take advantage of moving the directory one step up using the double dots ../. If the attacker finds the entry point, which in this case get.php?file=, then the attacker may send something as follows, http://webapp.thm/get.php?file=../../../../etc/passwd

Suppose there isn't input validation, and instead of accessing the PDF files at /var/www/app/CVs location, the web application retrieves files from other directories, which in this case /etc/passwd. Each .. entry moves one directory until it reaches the root directory /. Then it changes the directory to /etc, and from there, it read the passwd file.

As a result, the web application sends back the file's content to the user.

Similarly, if the web application runs on a Windows server, the attacker needs to provide Windows paths. For example, if the attacker wants to read the boot.ini file located in c:\boot.ini, then the attacker can try the following depending on the target OS version:

http://webapp.thm/get.php?file=../../../../boot.ini or

http://webapp.thm/get.php?file=../../../../windows/win.ini

The same concept applies here as with Linux operating systems, where we climb up directories until it reaches the root directory, which is usually c:\.

Sometimes, developers will add filters to limit access to only certain files or directories. Below are some common OS files you could use when testing. 

Location	Description
/etc/issue	contains a message or system identification to be printed before the login prompt.
/etc/profile	controls system-wide default variables, such as Export variables, File creation mask (umask), Terminal types, Mail messages to indicate when new mail has arrived
/proc/version	specifies the version of the Linux kernel
/etc/passwd	has all registered user that has access to a system
/etc/shadow	contains information about the system's users' passwords
/root/.bash_history	contains the history commands for root user
/var/log/dmessage	contains global system messages, including the messages that are logged during system startup
/var/mail/root	all emails for root user
/root/.ssh/id_rsa	Private SSH keys for a root or any known valid user on the server
/var/log/apache2/access.log	the accessed requests for Apache  webserver
C:\boot.ini	contains the boot options for computers with BIOS firmware

Read More