This request tries to contact something located at the URL
/shell and which takes as parameter a set of shell commands to execute.
While the shell commands to execute may seem obfuscated at first, most chances are that actually they are not. Shell commands may often contain characters which have a special meaning in HTTP URLs, so to keep the commands from being corrupted by either the HTTP client or server the easiest solution is simply to HTTP encode it completely (this is less a matter of obfuscation than the fact that the attacker most likely don't care about the URL readability).
/shell URL which (fortunately!) was not found on your server, there are two main possibilities:
- This may be the name of a resource specific to the service targeted by the attacker. The name of the file that this commands tries to download seems to indicate it is expecting an ARM device, so the attacker may be a bot scanning the Internet for a specific vulnerable embedded device where this
/shell URL is present and enabled by default (for instance a debug feature left enabled by a manufacturer. Bad things happens...).
- Another possibility is that this request is not the first step of the attack. The attacker may already have taken one or several step(s) before this one which, when facing a vulnerable server, would have lead to the creation of this
/shell script server-side. These previous steps could have been really anything which would have coerced the server or the service it runs in somehow generating this
/shell file or accepting to upload it.
In your comments, regarding the second option you seem to wonder why to act in two (or more) steps. When an attacker gets its first foot on a target, most often he has to face various limitations in terms of size and content of the payload he may execute (for instance he may be able to upload/create only ASCII files, or the content must be shorter than 100 characters, etc.).
Therefore, in order to fully-compromise a machine, he will first drop a first-stage payload which will be the bare minimum allowing him to download a full fledged binary payload as a second step. The classical way is to create server-side a script which will run any shell command passed as parameter (a classical web shell). Access to such web shell would produce exactly the same kind of log than quoted in your question.
And at last, as to why proceed with the following steps if the previous apparently did not work, again two possibilities:
- Depending on the exploit details, it happens that the attacker may have no definitive feedback during the first steps allowing him to clearly define if the server is vulnerable or not. He will know it if the attack succeeded and contacting `/shell' URL does not throw a 404 error message but properly download and execute the second stage payload.
- Some bots scanning the Internet are developed in a quick and dirty way and just blindly execute all steps of a given attack on all servers found in an IP range, ignoring the server response. Vulnerable machines, by executing the second stage payload, will call-back the attacker by themselves.