Announcement

Collapse
No announcement yet.

Question on incident urls

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Question on incident urls

    Hi there,

    I have Imunify360 running on both my VPS's and have a quick question on some of the incidents that appear.

    Certain incidents will list a url of a file or location that has been blocked - my question is do these files always exist, or could they be looking for known suspicious filenames on the off chance that they're there?

    EG I'll see a notification about Joomla, WordPress or Lavarel but there are non sites of this type on my server. I've attached a screen grab of an example of these notifications (eg IM360 WAF: Lavarel .env file access, and IM360 WAF: Infectors. Dirb like fuzzing).

    Similarly, on my other VPS I see IM360: Block access to shell which references a url/file which I don't believe exists: MV:/electronic-christmas-cards/.well-known/wso112233.php. Is this just them looking for known dodgy files that could be there, rather than them actually being in its?

    I've attached three grabs - would really appreciate it if you could take a look and put my mind at rest.

    Thanks.



    Attached Files

  • #2
    Hello Matt,

    The rules in a WAF like Imunify360 often contain patterns that match known paths and filenames used by attackers. When a request is made to a URL that matches one of these patterns, the WAF blocks it. This does not necessarily mean that the file or path actually exists on your server; it's just that the request made to the server looked suspicious because it matched a known attack pattern. I.e. there was a request to .well-known/wso112233.php that was denied, although shell is not necessarily exists.

    Best way to confirm it's absence, is to refer to malware incidents on your VPS, for example by:
    Code:
     imunify360-agent malware malicious list --search shell
    By the same token you may see incidents referencing Joomla, WordPress, or Laravel paths, even if you don’t host sites using these systems. It is expected that some rules should be automatically disabled by tags if there are no CMS detected on a host, although this should not be an issue.

    Fuzzing detects are likely just bots or passive scanners. I hope this answers your questions! Have a nice one and feel free to ask more.

    Comment


    • #3
      Thanks for your reply!

      Wouldn’t any malware incidents be listed in the actual Imunfy360 panel already (there is nothing in the history etc). What would I expect to see by running that line of code you shared?

      Many thanks again.

      Comment


      • #4
        Wouldn’t any malware incidents be listed in the actual Imunfy360 panel already
        Indeed, the Malware Scan Malicious tab or the History tab will provide enough data to conclude whether there were malicious detects. UI also supports filtering:


        The CLI command provided is an analogue for Malicious tab highlights the same data:

        Useful to check if any infected files remain not cleaned/deleted on a server but no content differences.

        If there is nothing on the Dashboard, this means the detected attack was an attempt to access a non-existing backdoor on the VPS. In general access to dot files is an attempted reconnaissance, while a request for a shell like "wso112233.php" (Web Shell by oRb) doesn't necessarily mean the server has been compromised but an attacker/bot to discover a known web shell by path.

        I hope this clarifies the ModSec incident nature and provides some comfort )

        Thank you for staying vigilant!​

        Comment

        Working...
        X