{"id":287,"date":"2014-05-15T02:09:24","date_gmt":"2014-05-15T02:09:24","guid":{"rendered":"https:\/\/qbytes.cloud\/?p=287"},"modified":"2014-05-15T02:09:24","modified_gmt":"2014-05-15T02:09:24","slug":"root-compromised","status":"publish","type":"post","link":"https:\/\/www.qbytes.cloud\/index.php\/2014\/05\/15\/root-compromised\/","title":{"rendered":"Root Compromised"},"content":{"rendered":"<p>Check the server if it is root compromised.<\/p>\n<pre class=\"brush: bash; title: ; notranslate\" title=\"\">\nlsattr \/usr\/bin\n<\/pre>\n<p>Root compromised output. All of those files are set to immutable and append only. That&#8217;s what the &#8220;ia&#8221; you see is.<\/p>\n<pre class=\"brush: bash; title: ; notranslate\" title=\"\">\n&#x5B;root@mail ~]# lsattr \/usr\/bin\ns---ia------- \/usr\/bin\/bzcmp\ns---ia------- \/usr\/bin\/getkeycodes\ns---ia------- \/usr\/bin\/enc2xs\ns---ia------- \/usr\/bin\/mail-files\ns---ia------- \/usr\/bin\/chage\ns---ia------- \/usr\/bin\/mdeltree\ns---ia------- \/usr\/bin\/nslookup\ns---ia------- \/usr\/bin\/semodule_link\ns---ia------- \/usr\/bin\/mbchk\ns---ia------- \/usr\/bin\/rpcgen\ns---ia------- \/usr\/bin\/lkbib\ns---ia------- \/usr\/bin\/dig\ns---ia------- \/usr\/bin\/webazolver\ns---ia------- \/usr\/bin\/pstruct\ns---ia------- \/usr\/bin\/spfd\ns---ia------- \/usr\/bin\/linux64\ns---ia------- \/usr\/bin\/semodule_expand\ns---ia------- \/usr\/bin\/readlink\ns---ia------- \/usr\/bin\/as\ns---ia------- \/usr\/bin\/makedb\ns---ia------- \/usr\/bin\/seq\ns---ia------- \/usr\/bin\/id\ns---ia------- \/usr\/bin\/colcrt\ns---ia------- \/usr\/bin\/pod2man\ns---ia------- \/usr\/bin\/zipnote\ns---ia------- \/usr\/bin\/hcitool\ns---ia------- \/usr\/bin\/lftp\ns---ia------- \/usr\/bin\/run-with-aspell\ns---ia------- \/usr\/bin\/&#x5B;\ns---ia------- \/usr\/bin\/perl\ns---ia------- \/usr\/bin\/mailstat\ns---ia------- \/usr\/bin\/ecryptfs-setup-swap\ns---ia------- \/usr\/bin\/lpstat.cups\ns---ia------- \/usr\/bin\/linux32\ns---ia------- \/usr\/bin\/ipcclean\ns---ia------- \/usr\/bin\/pkill\ns---ia------- \/usr\/bin\/mzip\ns---ia------- \/usr\/bin\/mcookie\ns---ia------- \/usr\/bin\/pm-restart\ns---ia------- \/usr\/bin\/rcp\ns---ia------- \/usr\/bin\/fgconsole\n\n<\/pre>\n<p>Non root compromised<\/p>\n<pre class=\"brush: bash; title: ; notranslate\" title=\"\">\n&#x5B;root@austin ~]# lsattr \/usr\/bin\n-------------e- \/usr\/bin\/pigz\n-------------e- \/usr\/bin\/isosize\n-------------e- \/usr\/bin\/php\n-------------e- \/usr\/bin\/system-config-firewall\n-------------e- \/usr\/bin\/ftpdctl\n-------------e- \/usr\/bin\/berkeley_db_svc\n-------------e- \/usr\/bin\/wftopfa\n-------------e- \/usr\/bin\/yum-builddep\n-------------e- \/usr\/bin\/tic\n-------------e- \/usr\/bin\/ptardiff\n\n<\/pre>\n<p>Other checks:<\/p>\n<p>I would check the following:<\/p>\n<p>    Logs. If you have root access you should check things like history which will give you command history and log files in \/var\/logs.<\/p>\n<p>    Baseline. If you have a baseline like file hashes to work with for application and system files this will help a lot. You can also use backups to compare a previous state. If using a backup to compare files, use a slightly older one if you can. The site may have been compromised a while before and it is only now that the redirect has been activated.<\/p>\n<p>    Check any includes. The files may not be on your server. They may be script includes such as <script src=\u201dhttp:\/\/baddomain.com\/s.js\u201d \/> or iframe type tags. Also do not exclude images, PDFs of Flash (SWF), video files. It is a fairly common trick to embed links in to files of a different content type. I would suggest you inspect them by hand particularly at the start and end of a file. The file may be completely a link\/html\/javascript or may be a legitimate image file with a link trailing at the end of the file.<\/p>\n<p>    Check for unusual file dates, sizes and permissions e.g. 777.<\/p>\n<p>    Check cron jobs for unusual jobs. Someone compromising a system will often leave a back door to get back in again and again. Cron is a very popular way to do this if they managed to get that far.<\/p>\n<p>    Check for the absence of files, you may not be able to have access to logs but the absence of them is equally a tell tail sign that someone has cleaned up after themself.<\/p>\n<p>    Use search engines. Not surprising search engines are great at finding everything. Use directives like site: e.g. site:yoursitehere.com baddomain.com see if you get any hits.<\/p>\n<p>    Often a link or redirect will be obfuscated so long javascript code with single letter variables should be analyzed carefully.<\/p>\n<p>    Do a packet capture with a tool like Wireshark or tcpdump from a secure workstation to the site. Save it to file and search the file for a parts of the url.<\/p>\n<p>    Check database records that may be queried or updated. The link could be injected in the database not the PHP.<\/p>\n<p>    Don't exclude the client's workstation. Use a free online virus scanner if need be. Also check nslookup and see what that resolves to. Check browser extensions, clear cache and check hosts files.<br \/>\nI would check the following:<\/p>\n<p>    Logs. If you have root access you should check things like history which will give you command history and log files in \/var\/logs.<\/p>\n<p>    Baseline. If you have a baseline like file hashes to work with for application and system files this will help a lot. You can also use backups to compare a previous state. If using a backup to compare files, use a slightly older one if you can. The site may have been compromised a while before and it is only now that the redirect has been activated.<\/p>\n<p>    Check any includes. The files may not be on your server. They may be script includes such as <script src=\u201dhttp:\/\/baddomain.com\/s.js\u201d \/> or iframe type tags. Also do not exclude images, PDFs of Flash (SWF), video files. It is a fairly common trick to embed links in to files of a different content type. I would suggest you inspect them by hand particularly at the start and end of a file. The file may be completely a link\/html\/javascript or may be a legitimate image file with a link trailing at the end of the file.<\/p>\n<p>    Check for unusual file dates, sizes and permissions e.g. 777.<\/p>\n<p>    Check cron jobs for unusual jobs. Someone compromising a system will often leave a back door to get back in again and again. Cron is a very popular way to do this if they managed to get that far.<\/p>\n<p>    Check for the absence of files, you may not be able to have access to logs but the absence of them is equally a tell tail sign that someone has cleaned up after themself.<\/p>\n<p>    Use search engines. Not surprising search engines are great at finding everything. Use directives like site: e.g. site:yoursitehere.com baddomain.com see if you get any hits.<\/p>\n<p>    Often a link or redirect will be obfuscated so long javascript code with single letter variables should be analyzed carefully.<\/p>\n<p>    Do a packet capture with a tool like Wireshark or tcpdump from a secure workstation to the site. Save it to file and search the file for a parts of the url.<\/p>\n<p>    Check database records that may be queried or updated. The link could be injected in the database not the PHP.<\/p>\n<p>    Don't exclude the client's workstation. Use a free online virus scanner if need be. Also check nslookup and see what that resolves to. Check browser extensions, clear cache and check hosts files.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Check the server if it is root compromised. lsattr \/usr\/bin Root compromised output. All of those files are set to immutable and append only. That&#8217;s what the &#8220;ia&#8221; you see is. &#x5B;root@mail ~]# lsattr \/usr\/bin s&#8212;ia&#8212;&#8212;- \/usr\/bin\/bzcmp s&#8212;ia&#8212;&#8212;- \/usr\/bin\/getkeycodes s&#8212;ia&#8212;&#8212;- \/usr\/bin\/enc2xs s&#8212;ia&#8212;&#8212;- \/usr\/bin\/mail-files s&#8212;ia&#8212;&#8212;- \/usr\/bin\/chage s&#8212;ia&#8212;&#8212;- \/usr\/bin\/mdeltree s&#8212;ia&#8212;&#8212;- \/usr\/bin\/nslookup s&#8212;ia&#8212;&#8212;- \/usr\/bin\/semodule_link s&#8212;ia&#8212;&#8212;- \/usr\/bin\/mbchk s&#8212;ia&#8212;&#8212;- \/usr\/bin\/rpcgen &#8230; <a title=\"Root Compromised\" class=\"read-more\" href=\"https:\/\/www.qbytes.cloud\/index.php\/2014\/05\/15\/root-compromised\/\" aria-label=\"Read more about Root Compromised\">Read more<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[102],"tags":[],"class_list":["post-287","post","type-post","status-publish","format-standard","hentry","category-security"],"_links":{"self":[{"href":"https:\/\/www.qbytes.cloud\/index.php\/wp-json\/wp\/v2\/posts\/287","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.qbytes.cloud\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.qbytes.cloud\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.qbytes.cloud\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.qbytes.cloud\/index.php\/wp-json\/wp\/v2\/comments?post=287"}],"version-history":[{"count":0,"href":"https:\/\/www.qbytes.cloud\/index.php\/wp-json\/wp\/v2\/posts\/287\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.qbytes.cloud\/index.php\/wp-json\/wp\/v2\/media?parent=287"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.qbytes.cloud\/index.php\/wp-json\/wp\/v2\/categories?post=287"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.qbytes.cloud\/index.php\/wp-json\/wp\/v2\/tags?post=287"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}