https://shelltrap.com/how-it-works/Recent content in How it works on ShelltrapHugoen-GBhttps://shelltrap.com/how-it-works/real-time-detection/Mon, 01 Jan 0001 00:00:00 +0000https://shelltrap.com/how-it-works/real-time-detection/<h2 id="the-problem-with-scheduled-scanning">The problem with scheduled scanning</h2> <p>A cron job that walks <code>/home</code> at three in the morning has one virtue: it is simple. Everything else about it is a compromise.</p> <p>A webshell uploaded at 09:15 has eighteen hours to be used before anything notices. In those eighteen hours it can be used to send mail, host a phishing page, pivot to another account or install a second backdoor somewhere the next scan will not look. By the time the scan reports, the file it finds is often not the interesting one any more — it is the one the attacker left behind on purpose.</p>https://shelltrap.com/how-it-works/upload-gate/Mon, 01 Jan 0001 00:00:00 +0000https://shelltrap.com/how-it-works/upload-gate/<h2 id="the-window-you-are-trying-to-close">The window you are trying to close</h2> <p>An attacker uploads a file through a vulnerable plugin at 09:15:02 and requests it at 09:15:04. Two seconds. Any detection mechanism with a latency longer than that has, in this case, documented an incident rather than prevented one.</p> <p>Asynchronous detection is genuinely valuable — most compromises are not exploited within seconds, and finding the shell in five seconds instead of eighteen hours changes everything about the cleanup. But if you want to <em>stop</em> the upload, the check has to happen while the request is still in flight.</p>