top of page

php2shell PHP RCE: Patch Order and Hunts for MSPs

Writer: Inception Security
Inception Security
1 day ago
15 min read

What this means for your clients: two critical bugs in PHP, the language behind WordPress, Magento and many other business websites, were fixed this morning, attackers are already moving, and whoever hosts each site has to update it today.

 

Your client's WordPress site is fully patched. Every plugin is current, the theme is current and the admin passwords are long. None of that matters this week, because the bug sits underneath WordPress, in PHP itself, the language that runs the site. If the PHP on that server is unpatched, the site is exposed no matter how tidy the app on top looks.

 

That is php2shell, the name researchers use for two critical remote code execution bugs in PHP, tracked as CVE-2026-109618 and CVE-2026-109619. The PHP security team rates both at 9.2 under CVSS v4.0 and released fixes on October 21. Details were meant to stay quiet until a coordinated disclosure on October 22, but a Hacker News post broke the embargo on October 20, and the week has moved fast since.

 

What we know and what we do not

 

PHP published its security advisory with the release on October 21, rating both bugs critical and saying an update is the only complete fix. Before the release, watchTowr's CEO told BleepingComputer the bugs were real and that he believed his team had reproduced CVE-2026-109618, and PHP now says it has a demonstrated exploit against Apache with mod_php. Researchers describe the result as a web request that gets the server to run commands.

 

PHP fixed both bugs on October 21 in 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and its advisories list every earlier release on those branches as affected, while 8.1 and older get no official update beyond minimal source backports PHP posted for 7.4, 8.0 and 8.1.

 

CVE-2026-109618 is remote code execution through out-of-memory handling that can leave request data half set up, and CVE-2026-109619 is remote code execution through stale state a worker keeps after a request's memory is freed. PHP says every install serving web requests is at risk, and Apache with mod_php most of all.

 

Wiz, which published its own analysis after the release, describes the common thread as memory safety bugs when PHP handles fatal or out-of-memory errors mid-request, leaving corrupted state that a later request or worker reuses. Sansec says the earliest affected code path dates to PHP 5.4.0, released in 2012. PHP's advisory sets no lower bound, so treat anything older than the fixed releases as exposed. Wiz's per-CVE breakdown pairs the bugs differently from PHP's advisory, so this post follows PHP's naming.

 

The picture changed overnight. Cloudflare reported early attacks at 07:43 UTC on October 21, according to Sansec, which says Cloudflare keeps updating its rules as attackers try new methods. That moves php2shell from a bug you plan around to a bug you patch now.

 

Since the release, Sansec says the technical writeups and an exploit tool are public, so it expects mass exploitation. Sansec also reports that Calif, one of the research teams, confirmed unauthenticated remote code execution against Magento, WordPress, Drupal, Joomla, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS.

 

Huntress had seen no exploitation in partner environments as of October 20, per its post. As of about 7:08 AM Arizona time, NVD has no record of either CVE yet and CISA's Known Exploited Vulnerabilities catalog lists neither.

 

Why this one reaches so far

 

Most web bugs live in one plugin or one product. This one lives in the engine under WordPress, Magento, Drupal, Joomla, Laravel and WHMCS, and under control panels such as cPanel and Plesk. Huntress points out that plenty of PHP is hidden, too. Vendor software on Windows can bundle php.exe or php-cgi.exe, and shared hosting runs PHP that nobody on your team ever installed.

 

Age is the second problem. PHP supports only 8.2 and later, so 8.1 and older get no regular release. PHP did post minimal source backports for 7.4, 8.0 and 8.1, and some distros and LTS vendors ship backported fixes, so check with your vendor first. Anything older than 7.4 with no vendor fix, or any install you cannot rebuild from source, needs an upgrade, isolation or a shutdown.

 

Yesterday's Cairn post showed attackers leaving small PHP uploader shells after a day of patient probing. A core PHP remote code execution bug is a much faster road to the same web shell, which is why the hunts below borrow from that post.

 

What the stopgaps can and cannot do

 

Cloudflare deployed emergency WAF rules for all its customers, including the free plan, and its CTO Dane Knecht calls them a stopgap, according to Sansec. On paid plans, check that the Managed Ruleset is deployed in block mode. PHP, Sansec and Wiz all say updating PHP is the only complete fix. Sansec and ma.ttias.be add an important catch: the WAF only helps if the origin server accepts web traffic from Cloudflare addresses alone. If attackers can reach the server directly, the rules never see them.

 

Sansec now publishes a set of temporary mitigations, and says they are temporary and partial and that none of them replaces the patch. The first is to block multipart/form-data requests at the web server. ma.ttias.be notes this is not enough on Apache with mod_php, where Calif also triggered CVE-2026-109618 with a normal urlencoded form post. The multipart block also breaks file uploads and some checkout forms, so place a test order and remove the block after patching.

 

The second is the Cloudflare proxy with the origin locked down as above.

 

The third is to take PHP servers offline or, as a weaker partial filter, reject anything other than GET and HEAD. A method filter does not make PHP safe.

 

Sansec, citing Calif, also lists two partial php.ini settings, session.upload_progress.enabled set to 0 and memory_limit set to -1, applied in php.ini, in every PHP-FPM pool (php_admin_flag for the upload progress switch, php_admin_value for memory_limit), or, for mod_php, in php.ini followed by an Apache restart. Restart every PHP-FPM worker too; a reload is not enough.

 

PHP's own advisory adds interim settings per bug, such as memory_limit=-1 set with php_admin_value in the FPM pool or Apache config so apps cannot override it (and no RLIMIT_AS or RLIMIT_DATA caps, which PHP warns can trigger the bug), a low post_max_size, session.upload_progress.enabled=0 and, on PHP 8.5, fatal_error_backtraces=0. For the upload progress setting, PHP says to use php.ini, the FPM pool or the server config, not ini_set() or .user.ini. PHP also says to remove invalid or deprecated per-request settings such as bad php_value lines, to pair memory_limit=-1 with a container or cgroup limit, to restart every worker, and says plainly that they reduce exposure but do not make an install safe.

 

App maintenance modes do not help. On Apache with mod_php, PHP says the attack can fire before any application code runs, and Sansec says built-in maintenance modes do not help because PHP still parses each request first. PHP core developer Gina Peter Banyard called taking a PHP server offline the most sensible option before the release, and PHP's advisory says only an update is a complete solution. Several Dutch sites, including Tweakers, the House of Representatives and the Dutch NCSC, went offline on October 21 as a precaution. NSA Cyber weighed in at 6:45 AM Arizona time on October 21, telling every organization that uses PHP to be ready for the update and, if an immediate update is not feasible, to take the system offline until it can be fully mitigated. NSA said it will follow up with more specific guidance.

 

One trap is worth knowing. On Apache or nginx, disabling only the PHP handler can make the server hand out .php source code as plain text, passwords included. Stop PHP entirely and have the web server answer every request with a static maintenance page, so .php files are neither run nor served as text.

 

What to change this week

 

Start with an inventory. List every server, site and appliance that runs PHP, the version on it and who owns the patch. For hosted sites, ask each host now for the PHP version per site and when they will update. Anyone who relies on the Remi repository should know it will not publish updates on October 21, per PHP's own advisory, so switch to distro packages or build from source. Distros and LTS vendors got the patches in advance, so check your vendor's packages first.

 

Back up each site and its database before you touch anything. Then patch in order of exposure. Online shops and anything that takes payments go first, then client portals, WHMCS and control panels, then internal tools. Sites on 8.1 or older get a vendor backport, PHP's source backport where one exists for 7.4, 8.0 or 8.1, an upgrade, isolation behind a VPN, or go offline. If a site is not essential, our reading is that switching it off until it is patched costs less than cleaning up a web shell.

 

This is patch management with a deadline measured in hours at most, and the fix is out, so line up owners now. Agree in advance who can approve an emergency change, who places the test order after a multipart block, and who calls the host if a site stays on old PHP past lunch. Threat hunting then tells you whether an attacker left a shell, file or process behind before the fix. Host hunts cannot see the memory disclosure that Wiz and Sansec describe, where freed worker memory can come back to the client in a PHPSESSID response cookie, so rotate the passwords, API keys, session secrets and TLS private keys on any server that was exposed. Run the hunts below before you patch and again after. Treat any confirmed hit as incident response.

 

Six hunts to run (test first)

 

These hunts look for behavior and do not depend on the root cause, so they can run today. Every query is a template, so check field names against your own data before you trust a result. Start from the leak on October 20 at 15:20 UTC and run forward, except where a hunt asks for a longer baseline, as Hunt 5 does. An empty result is not a clean bill of health, because much PHP sits on shared hosting with no EDR at all. The table under the hunts, "Interpret before you escalate", says what is benign and what is not.

 

Hunt 1 on the host: find every PHP install (test first)

 

On Linux, run the version check and ask the package manager what is installed. On Windows, look for php.exe and php-cgi.exe outside the paths you expect, since bundled vendor copies are the ones teams forget. Flag anything below 8.5.12, 8.4.27, 8.3.36 or 8.2.35, and treat 8.1 or older as needing a backport or an upgrade. php -v only shows the command line PHP on the path, and distro packages often backport fixes without changing the version number, so check each web handler and your vendor's advisory for the CVE IDs too.

 

Linux

 

php -v 2>/dev/null
dpkg -l 2>/dev/null | grep -i php
rpm -qa 2>/dev/null | grep -i php
ls -d /opt/cpanel/ea-php*/root/usr/bin/php /opt/plesk/php/*/bin/php /opt/remi/php*/root/usr/bin/php /usr/local/bin/php 2>/dev/null
ps -eo comm,args | grep -E 'php-fpm|php-cgi|lsphp|frankenphp|httpd|apache2' | grep -v grep

 

Windows

 

Get-PSDrive -PSProvider FileSystem | ForEach-Object { Get-ChildItem -Path $_.Root -Recurse -Include php.exe,php-cgi.exe -ErrorAction SilentlyContinue } | Select-Object FullName, LastWriteTime

 

On cPanel and Plesk, list the PHP handler assigned to each domain in the panel. For Apache with mod_php, the CLI version can differ from the module, so check the libphp or mod_php package version, or run apachectl -M | grep php to confirm the module is loaded and then match its package. For hosted sites with no shell access, the host has to answer the version question for you.

 

Hunt 2 in Falcon CQL: PHP workers spawning shells and tools (test first)

 

Search 1 catches a PHP worker or web server process starting a shell, an interpreter, a download tool or a recon command. Search 2 looks for reverse shell patterns in the command line. Some admin scripts legitimately call curl or a shell, so note which parents and children are normal on each host before you alert. PHP's system() and exec() usually run commands through sh -c or cmd.exe /c, so curl or whoami often shows up as a grandchild; when a PHP worker starts a shell, look at that shell's children too. Search 2 only sees process launch arguments, so a reverse shell written in PHP inside the worker will not appear there; check worker network connections and script contents separately. The table shows aid, the sensor ID; add a join to your host lookup if you want host names in the results.

 

Search 1: PHP workers starting shells and tools

 

#event_simpleName=ProcessRollup2
| ParentBaseFileName=/^(php-fpm.*|php(-cgi)?[0-9.]*(\.exe)?|lsphp.*|frankenphp|httpd(\.exe)?|apache2|w3wp\.exe)$/i
| FileName=/^(sh|bash|dash|cmd\.exe|powershell\.exe|python.*|perl|curl|curl\.exe|wget|wget\.exe|nc|nc\.exe|certutil\.exe|whoami|whoami\.exe|id|uname|ipconfig\.exe)$/i
| table([@timestamp, aid, ParentBaseFileName, FileName, CommandLine])

 

Search 2: reverse shell patterns

 

#event_simpleName=ProcessRollup2
| CommandLine=/(\/dev\/tcp\/|fsockopen|mkfifo)/i
| table([@timestamp, aid, ParentBaseFileName, FileName, CommandLine])

 

Hunt 3 in Microsoft Defender KQL: child processes and new PHP files (test first)

 

Search 1 covers the same parent and child pairs in DeviceProcessEvents. Search 2 finds new .php files written by those processes in DeviceFileEvents. Plugin updates write PHP too, so check the folder and the timing before you call a file hostile.

 

Search 1: child processes

 

DeviceProcessEvents
| where Timestamp > datetime(2026-10-20T15:20:00Z)
| where InitiatingProcessFileName matches regex @"(?i)^(php-fpm.*|php(-cgi)?[0-9.]*(\.exe)?|lsphp.*|frankenphp|httpd(\.exe)?|apache2|w3wp\.exe)$"
| where FileName startswith "python" or FileName in~ ("sh","bash","dash","cmd.exe","powershell.exe","perl","curl","curl.exe","wget","wget.exe","nc","nc.exe","certutil.exe","whoami","whoami.exe","id","uname","ipconfig.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine

 

Search 2: new PHP files

 

DeviceFileEvents
| where Timestamp > datetime(2026-10-20T15:20:00Z)
| where ActionType in ("FileCreated","FileRenamed","FileModified") and FileName endswith ".php"
| where InitiatingProcessFileName matches regex @"(?i)^(php-fpm.*|php(-cgi)?[0-9.]*(\.exe)?|lsphp.*|frankenphp|httpd(\.exe)?|apache2|w3wp\.exe)$"
| project Timestamp, DeviceName, FolderPath, FileName, InitiatingProcessFileName

 

Hunt 4 in Elastic and Kibana: the same pairs in ECS (test first)

 

Search 1 maps the parent and child lists to process.parent.name and process.name. Search 2 looks for PHP files created under upload, image, cache or temp paths. Search 2 uses leading wildcards, which Kibana allows when query:allowLeadingWildcards is on, which is the default, and file.path is case sensitive, so the query lists capitalized variants for Windows paths. If your web hosts ship no endpoint data, both come back empty for the wrong reason.

 

Search 1: parent and child pairs

 

event.category:process and event.type:start and process.parent.name:(php-fpm* or php* or lsphp* or "frankenphp" or "httpd" or "httpd.exe" or "apache2" or "w3wp.exe") and process.name:("sh" or "bash" or "dash" or "cmd.exe" or "powershell.exe" or python* or "perl" or "curl" or "curl.exe" or "wget" or "wget.exe" or "nc" or "nc.exe" or "certutil.exe" or "whoami" or "whoami.exe" or "id" or "uname" or "ipconfig.exe")

 

Search 2: PHP files in upload, image, cache or temp paths

 

event.category:file and event.type:(creation or change) and file.extension:"php" and file.path:(*upload* or *Upload* or *image* or *Image* or *cache* or *Cache* or *tmp* or *temp* or *Temp* or *Tmp*)

 

Hunt 5 in Splunk: first seen pairs from CIM (test first)

 

This search uses the Endpoint.Processes data model, so it only works if your EDR data is CIM mapped. Run it over at least 30 days so first seen means something, and if your Splunk version does not expand wildcards inside IN for tstats, swap those values for OR clauses such as Processes.parent_process_name="php*", then look hardest at pairs that first appeared after the leak.

 

| tstats summariesonly=false min(_time) as first_seen count from datamodel=Endpoint.Processes where Processes.parent_process_name IN ("php-fpm*","php*","lsphp*","frankenphp","httpd","httpd.exe","apache2","w3wp.exe") AND Processes.process_name IN ("sh","bash","dash","cmd.exe","powershell.exe","pwsh.exe","python*","perl","curl","curl.exe","wget","wget.exe","nc","nc.exe","certutil.exe","whoami","whoami.exe","id","uname","ipconfig.exe") by Processes.dest Processes.parent_process_name Processes.process_name
| sort 0 - first_seen
| convert ctime(first_seen)

 

Hunt 6 on the web root: new PHP files, cron jobs and accounts (test first)

 

This one needs no EDR, which makes it the hunt for shared hosting. It lists PHP files that are new or changed since the leak in upload, image, cache and temp folders, small files that handle uploads, the current cron entries and every local account with its shell, to compare against a known baseline, and a burst of PHP fatal errors around memory_limit, which Sansec says is worth investigating. PHP also warns that clean logs are not proof of safety. The file checks use inode change time, which an attacker cannot reset with touch, and also catch .phtml, .phar, .htaccess and .user.ini changes inside upload, image, cache and temp folders. Check the web root's own .htaccess and .user.ini by hand. The last loop counts PHP fatal and memory errors per hour for each Apache, nginx and PHP-FPM error log, in log order, and shows the last 48 hour buckets that had any errors, so a spike stands out. Treat it as a rough view: timestamp formats differ by log, so confirm a spike by reading the lines around it. nginx logs FPM errors as "FastCGI sent in stderr" lines, which the pattern still catches. Adjust the paths for your distro and use zgrep for rotated logs. On shared hosting without root you will only see your own cron and logs, so ask the host for the rest. Set WEBROOT to your site path first.

 

WEBROOT=/var/www
find "$WEBROOT" -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.php[0-9]' -o -name '.htaccess' -o -name '.user.ini' \) -newerct '2026-10-20 15:20 UTC' \( -ipath '*upload*' -o -ipath '*image*' -o -ipath '*cache*' -o -ipath '*tmp*' -o -ipath '*temp*' \) -print
find "$WEBROOT" -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \) -size -5k -newerct '2026-10-20 15:20 UTC' -exec grep -lE 'move_uploaded_file|\$_FILES' {} +
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
ls -laR /etc/cron.d /var/spool/cron 2>/dev/null
ls -la --time-style=full-iso /etc/crontab /etc/cron.* 2>/dev/null
cat /etc/crontab /etc/cron.d/* 2>/dev/null
awk -F: '{print $1, $3, $6, $7}' /etc/passwd
for f in /var/log/apache2/error.log /var/log/httpd/error_log /var/log/nginx/error.log /var/log/php*-fpm.log /var/log/php-fpm/*.log; do
  [ -r "$f" ] || continue; echo "== $f"
  grep -E 'Allowed memory size of [0-9]+ bytes exhausted|Out of memory|PHP Fatal error|Maximum execution time' "$f" | grep -oE '[0-9]{4}/[0-9]{2}/[0-9]{2} [0-9]{2}|[A-Z][a-z]{2}[[:space:]]+[0-9]{1,2} [0-9]{2}:|[0-9]{4}-[0-9]{2}-[0-9]{2}[ T][0-9]{2}|[0-9]{2}-[A-Z][a-z]{2}-[0-9]{4} [0-9]{2}' | uniq -c | tail -48
done

 

Interpret before you escalate

 

What you see

Benign read

When to escalate

PHP worker starting a shell, curl or wget

A known admin or backup script that does this every day

Anything new since the leak. Investigate at once; if the script and change records do not explain it, isolate the host and keep web and PHP logs

Reverse shell pattern in a command line

fsockopen and mkfifo have normal uses in some software

The parent is a PHP worker or the script is unknown

New .php file in an upload, image or cache folder

A plugin or theme update writing its own files

No matching update, small size, or upload handling code inside

whoami, id or uname from a PHP parent

A known monitoring script

Unknown parent script or a first seen pair

New cron entry or local account

A change your team made and can name

Nobody can name it

PHP 8.1 or older on any host

None. No official fix is coming

Always: upgrade, isolate behind a VPN or take it offline

Empty across all six hunts

Nothing matched the data you have

Not proof: confirm logs and sensors cover the web host, or ask the host

 

Wiz also names three signals worth watching until every server is patched: unusual multipart requests followed by memory limit errors or repeated HTTP 500 responses, unexpectedly large or malformed PHPSESSID cookies in server responses, and unexplained PHP worker churn. Hunt 6's log check and Alert 2 partly cover the first, though neither ties the multipart request to the errors that follow, so line them up by time yourself. The other two need web server or WAF logs that record cookie size and FPM or Apache logs that record worker restarts.

 

What to alert on (test first)

 

Hunts look back once, and alerts keep watching. These three rules turn the hunts above into standing detections. Each is a template, so run it as a search for a few days and tune it before you let it page anyone.

 

Alert 1 in Falcon CQL and Defender KQL: web workers spawning shells and tools (test first)

 

Hunt 2 already does this job, so the simplest move is to save its Search 1 as a scheduled alert. The version below adds nginx to the parent list and pwsh.exe to the children, and keeps every child Hunt 2 has. In Falcon, ParentBaseFileName is the parent and FileName is the child. In Defender, the same pair is InitiatingProcessFileName and FileName. Backup jobs, monitoring agents and admin scripts can legitimately start curl or a shell from PHP, so record those parent and command line pairs per host and exclude them by name, never by wildcard.

 

Search 1: Falcon

 

#event_simpleName=ProcessRollup2
| ParentBaseFileName=/^(php-fpm.*|php(-cgi)?[0-9.]*(\.exe)?|lsphp.*|frankenphp|httpd(\.exe)?|apache2|nginx|w3wp\.exe)$/i
| FileName=/^(sh|bash|dash|cmd\.exe|powershell\.exe|pwsh\.exe|python.*|perl|nc|uname|whoami|whoami\.exe|id|curl|curl\.exe|wget|wget\.exe|nc\.exe|certutil\.exe|ipconfig\.exe)$/i
| table([@timestamp, aid, ParentBaseFileName, FileName, CommandLine])

 

Search 2: Defender

 

DeviceProcessEvents
| where InitiatingProcessFileName matches regex @"(?i)^(php-fpm.*|php(-cgi)?[0-9.]*(\.exe)?|lsphp.*|frankenphp|httpd(\.exe)?|apache2|nginx|w3wp\.exe)$"
| where FileName startswith "python" or FileName in~ ("sh","bash","dash","cmd.exe","powershell.exe","pwsh.exe","perl","nc","uname","whoami","whoami.exe","id","curl","curl.exe","wget","wget.exe","nc.exe","certutil.exe","ipconfig.exe")
| project Timestamp, DeviceId, DeviceName, ReportId, InitiatingProcessFileName, FileName, ProcessCommandLine

 

Alert 2 in Splunk: unusual multipart POSTs near session upload progress (test first)

 

PHP's advisory names session upload progress as one confirmed path for CVE-2026-109619, so requests that use it are worth a closer look until you patch. Most access logs do not record POST bodies, which means you will usually see only the method, the URI, the status, the size and, if you log it, the content type.

 

As in Hunt 5, if tstats does not expand the wildcard inside IN, rewrite the checkout exclusion as NOT Web.uri_path="/checkout*". Search 1 uses the CIM Web data model, so it needs web data mapped to CIM, and many mappings fill http_content_type from the response, so confirm yours holds the request Content-Type that a proxy or WAF logs. It flags multipart POSTs to any path outside your known upload or checkout paths, since most PHP apps route clean URLs through index.php. Search 2 catches the default form field name, PHP_SESSION_UPLOAD_PROGRESS, where it shows up in logged data; change it if a site set its own session.upload_progress.name. It is normally a multipart body field, so this only works where a WAF or proxy logs request bodies. Real upload forms and checkout pages trip Search 1, so build the allow list from a normal week. An empty result proves nothing when bodies and content types are not logged.

 

Search 1:

 

| tstats count min(_time) as first_seen values(Web.status) as status from datamodel=Web where Web.http_method=POST Web.http_content_type="multipart/form-data*" NOT Web.uri_path IN ("/checkout*","/wp-admin/async-upload.php") by Web.src Web.dest Web.uri_path
| sort 0 - count
| convert ctime(first_seen)

 

Search 2:

 

index=* "PHP_SESSION_UPLOAD_PROGRESS"
| stats count by sourcetype, host

 

Alert 3 in Defender KQL: new PHP files in upload, image or cache folders (test first)

 

This rule builds on Hunt 3's Search 2, adds a folder filter and drops the writer filter so it catches PHP files written by any process. FolderPath holds the containing folder, FileName the file and InitiatingProcessFileName the writer. Cache plugins write PHP into cache folders all day, and deploys and plugin updates drop new files in bulk, so exclude known cache paths and suppress during change windows. A single small file in wp-content/uploads outside a deploy deserves a person.

 

DeviceFileEvents
| where ActionType in ("FileCreated","FileRenamed","FileModified") and FileName endswith ".php"
| where FolderPath matches regex @"(?i)[\\/](wp-content[\\/]uploads|uploads?|images?|cache|tmp|temp)([\\/]|$)"
| project Timestamp, DeviceId, DeviceName, ReportId, FolderPath, FileName, FileSize, InitiatingProcessFileName, InitiatingProcessCommandLine

 

Sources

 

 

What This Means for Your Team

 

Find every PHP install today, know who patches each one and update now, since the release is out. Use the stopgaps only to buy hours, run the hunts before and after the patch, and treat an empty hunt on a host with no EDR as a coverage gap rather than good news.

 

Inception Protection

 

Inception Protection is the Inception Security managed detection and response service, and it works with the Microsoft licenses you already have. We watch Defender and sign-in data in your Microsoft environment, dig into anything odd and work through containment with your team. Web hosting sits outside that environment, and its patching and logs stay with you or your host.

 

Inception Foresight

 

A website lives outside your Microsoft tenant, but the SMTP passwords, Microsoft 365 app passwords and API keys it holds can reach back in. To find out whether your Microsoft environment would catch suspicious activity, try the free Inception Foresight M365 Assessment: https://www.inceptionsecurity.com/m365assessment.

 

bg-map-white.png

INCEPTION SECURITY™

A cybersecurity company with in depth knowledge of the threat landscape and security controls.

NAVIGATION

Home

About 

Services

Partners

Privacy

Contact us

Cyber Incident

Terms and Conditions

GET IN TOUCH

Phone: +1 (888) 427-2937

© 2025 All Rights Reserved by INCEPTION SECURITY™ .

bottom of page