MALWARE-BACKDOOR JSP webshell backdoor detected

[legend1907]

Hi all,

 We use sourcefire in our company. Current version 6.2.2.
In the last 10 days, approximately 1000 MALWARE-BACKDOOR JSP webshell backdoor were detected.The source and destination IP information are constantly changing. Have you been living this situation lately? Is there any information on the subject in the Global?

[phil.hydea]

Yes this is being seen widely. Ensure the associated SNORT rules are in
blocking (Drop and Generate), if in an passive mode then block the bad
external IPs on your firewall.

[Hassan syed]

Yeah, its quite same here.. any idea how/what is the behaviour of the this variant? Doesnt find much information! 

[CodeMonkey]

Recently I had a bunch of these show up in my logs too. The thing that is confusing to me is that the security appliance makes it appear that all the traffic came from outside my network and was blocked. Basically someone was probing my network to see if anything was listening on this end. That's what I'm used to seeing and it's expected of course. 

Then I got concerned when I look at the Snort description for this item: This activity is indicative of malware activity on a host. In this case the MALWARE-BACKDOOR JSP webshell backdoor detected was detected.

That makes it look like this is evidence of an active bit of malware on my server. I'm guessing that the JSP in the malware name is "Java Server Pages" and I don't have Java installed on that server. The server comes up clean in malware scans too.

Is there a way to have any level of assurance that this was just probing from the outside and not evidence of something inside like the Snort description seems to indicate?

[legend1907]

.What the cisco employees think about the problem. If a botnet traffic, the global soc unit can be informed

[fredd8605]

I've had a very hard time getting any traction on this in the month I've been working with TAC on the hundreds of impact red, priority 1 alerts we've been getting because of this. I've only gotten to the point where they've confirmed with Talos that these incidents I'm logging in FMC and in IIS are generated from vulnerability scanners/URL fuzzers. I've installed the custom remediation blacklist plugin to automate blocking the external, non-us sources that trigger IPS blocks, but I haven't been able to get any feedback on IPS/snort rule precedence etc to ensure CORRECT classification for more specific strings in new rules. In our case, we're seeing the following:

".jsp?ppp=echo%20D3c3mb3r"

"/jbossass/jbossass.jsp?ppp=echo%20D3c3mb3r"

https://community.cisco.com/t5/security-documents/remediation-module-for-security-intelligence-blacklist/ta-p/3144850