With the recent discovery of malicious files like Stained_Heart_Red-600x500.png being found on servers across the web, it pushed me to put together this article on detecting this kind of threat. This is not a new technique, but seeing it show up again is a reminder that it still works because it is easy to overlook.
Files that appear harmless on the surface can carry payloads that stay hidden unless you take the time to inspect them properly. What I began finding were files that looked like images but were anything but harmless. Some were straight PHP scripts renamed to .png or .jpg. Others were crafted in a way that let them act like both an image and executable code depending on how they were accessed.
In this article, I walk through how I identify these files, how I confirm what they actually are, and how I track down where they came from.
Why Images Are a Perfect Hiding Spot
The wp-content/uploads/ directory is one of the most trusted parts of a WordPress install. It is writable, publicly accessible, and often filled with thousands of files that nobody reviews manually. That combination makes it a reliable place for malware to hide.
Most people assume that anything with an image extension is safe. That assumption breaks down quickly when servers allow execution in upload directories or when files are crafted to bypass basic checks. I have seen files that render as normal images in a browser but still contain working PHP payloads.
Another issue is that uploads are constantly changing. New files appear all the time, which makes it harder to notice when something does not belong. Attackers rely on that noise to blend in.
What These Files Usually Look Like
The filenames are usually designed to blend in with normal media. You will see names that look completely legitimate.
Stained_Heart_Red-600x500.png image-1.png header-final.jpg logo-new-optimized.png
At a glance, nothing stands out. The problem shows up when you inspect what the file actually contains. Some of these files are not images at all, while others contain valid image data with additional payloads appended to the end.
I have seen files that pass visual inspection but contain obfuscated PHP after the image footer. That type of file will sit unnoticed until something triggers it.
Quick Manual Checks That Expose Them
When something feels off, I go straight to the shell and check the file type. The file command is one of the fastest ways to spot mismatches.
file Stained_Heart_Red-600x500.png
A normal result should look like this:
Stained_Heart_Red-600x500.png: PNG image data, 600 x 500, 8-bit/color RGBA
If I see something like this, I know I am dealing with malware:
Stained_Heart_Red-600x500.png: PHP script, ASCII text
That mismatch alone is enough to justify digging deeper.
Searching Across the Entire Server
On servers with multiple sites, I do not limit the search to a single WordPress install. If one site is compromised, there is a good chance others on the same server were touched as well. I start from the root of the home directory and scan everything.
The goal here is not to find specific filenames, but to identify files that claim to be images but do not behave like real images.
find /home -type f \( -iname "*.png" -o -iname "*.jpg" -o -iname "*.jpeg" -o -iname "*.gif" \) -exec file {} \; | grep -v "image data"This filters out normal image files and leaves behind anything that is not recognized as valid image data. In most cases, the output should be empty. If it is not, those files are worth investigating.
When I review the results, I am looking for anything that does not make sense. A file with a .png extension that shows up as ASCII text or a PHP script is an immediate red flag. Even if the file is not actively malicious, it should not exist in that form.
On larger servers, this command can return a lot of data. When that happens, I narrow the scope to specific user directories or recently modified files to make it easier to work through.
find /home -type f -mmin -120 \( -iname "*.png" -o -iname "*.jpg" -o -iname "*.jpeg" -o -iname "*.gif" \) -exec file {} \; | grep -v "image data"This limits the search to files modified within the last 120 minutes, which is useful when you are tracking down a recent infection. Adjust the time window based on what you found earlier when checking timestamps.
I treat this as a quick filtering step, not a final answer. If a file shows up here, I inspect it manually and then connect it with other findings like log activity or modified files. The value in this step is narrowing thousands of files down to a small set that should not exist.
Detecting Embedded PHP in Image Files
Some files pass the file type check because they are technically valid images. That is where things get tricky. The file may render fine, but still have code appended to it that you will never see unless you actually inspect the contents.
My first attempt at solving this was using a simple recursive grep looking for <?php. It worked, but it also returned a lot of noise.
grep -R --binary-files=text "<?php" /home/*/public_html/wp-content/uploads/
When you run grep directly against binary image data, random byte sequences will occasionally match patterns like base64_decode or gzinflate. That leads to false positives that waste time.
What worked better for me was filtering the data first and only searching readable strings inside the file. That removes most of the random matches and makes the results much more reliable.
find /home/*/public_html/wp-content/uploads/ -type f \( -iname "*.png" -o -iname "*.jpg" -o -iname "*.jpeg" -o -iname "*.gif" \) -exec sh -c '
for file do
if strings "$file" | grep -Eiq "<\?php|base64_decode|gzinflate|shell_exec|eval\s*\("; then
echo "[ALERT] Suspicious strings found in: $file"
fi
done
' sh {} +This keeps the scan focused on files that are supposed to be images and only checks the parts of the file that could realistically contain readable code. It is not perfect, but it cuts down the noise enough that the results are actually usable.
I also pay attention to where the match occurs. A lot of these payloads are appended to the end of the file after the image data. Because of that, I sometimes narrow the scan down to just the tail of each file.
find /home/*/public_html/wp-content/uploads/ -type f \( -iname "*.png" -o -iname "*.jpg" -o -iname "*.jpeg" -o -iname "*.gif" \) -exec sh -c '
for file do
if tail -c 1024 "$file" | strings | grep -Eiq "<\?php|base64_decode|gzinflate|shell_exec|eval\s*\("; then
echo "[ALERT] Suspicious appended content in: $file"
fi
done
' sh {} +That approach tends to surface more meaningful results because it targets where the malicious code is usually placed. It also runs faster on large directories since it is not processing the entire file.
I do not rely on a single check when I am scanning for this. If a file shows up here and also fails a file type check or shows unusual behavior elsewhere, that is when I take a closer look. One signal on its own is not enough, but multiple signals lining up usually tells the real story.
A Detection Script I Use Regularly
When I want something repeatable, I use a small bash script that combines multiple checks instead of relying on a single signal. I treat detection as a combination of indicators rather than trying to prove something is malicious with one command. That approach keeps the results more reliable and easier to review.
The script checks whether the file is actually recognized as an image, then scans readable strings inside the file, and finally looks at the tail end where payloads are often appended. When more than one of those flags something, that is when I take a closer look.
#!/bin/bash
SEARCH_DIR="/home"
echo "Scanning for suspicious image files..."
find "$SEARCH_DIR" -type f \( -iname "*.png" -o -iname "*.jpg" -o -iname "*.jpeg" -o -iname "*.gif" \) | while read file; do
alert=0
FILE_TYPE=$(file "$file")
if [[ "$FILE_TYPE" != *"image data"* ]]; then
echo "[ALERT] Non-image file with image extension:"
echo "$file"
echo "$FILE_TYPE"
echo ""
alert=1
fi
if strings "$file" | grep -Eiq "<\?php|base64_decode|gzinflate|shell_exec|eval\s*\("; then
echo "[ALERT] Suspicious readable strings found in image:"
echo "$file"
echo ""
alert=1
fi
if tail -c 1024 "$file" 2>/dev/null | strings | grep -Eiq "<\?php|base64_decode|gzinflate|shell_exec|eval\s*\("; then
echo "[ALERT] Suspicious appended content found near end of file:"
echo "$file"
echo ""
alert=1
fi
if [[ "$alert" -eq 1 ]]; then
echo "---- Readable strings from end of file ----"
tail -c 400 "$file" 2>/dev/null | strings
echo ""
fi
done
echo "Scan complete."This keeps the scan focused on files that should be images and avoids treating every match as a problem. The file check helps catch anything that is not actually an image, while the strings checks focus on readable content instead of raw binary data. The tail check targets where malicious payloads are often appended, which tends to produce more meaningful results.
I do not expect this script to catch everything, and I do not treat it as a final answer. What it does is narrow things down to a manageable set of files that are worth inspecting manually.
What a Malicious Image File Looks Like Internally
When I open one of these files, what I usually find is not a completely fake image. In many cases, the image data is real and valid. That is what allows it to render normally in a browser and avoid suspicion during a quick check.
The difference is what comes after the image data. Attackers will often append PHP code to the end of the file so it stays hidden behind the legitimate content. Unless you inspect the file directly, you will never see that second part.
Here is a simplified example of what that can look like:
...PNG HEADER DATA...
<?php
eval(base64_decode('c29tZV9tYWxpY2lvdXNfY29kZQ=='));
?>The first portion of the file is normal image data. That part is what image viewers and browsers use when displaying the file. The second portion is PHP code that gets interpreted by the server if the file is executed in the right context.
This is why these files are easy to miss. If you open them normally, everything looks fine. The malicious part is effectively hidden behind valid data.
When I want to confirm this manually, I do not rely on editors that try to interpret the file. I use tools that show the raw contents.
tail -n 20 Stained_Heart_Red-600x500.png
or
strings Stained_Heart_Red-600x500.png | less
If there is appended code, it will usually show up clearly in the output. In most cases, it is located near the end of the file, which is why checking the tail is often enough.
Once you see one of these files in its raw form, it becomes much easier to recognize the pattern elsewhere. The key is understanding that the file can be both a valid image and a carrier for executable code at the same time.
Finding the Source of the Infection
Once I find a file like this, I stop focusing on the file itself and start tracing how it got there. Removing it without finding the entry point only delays the problem. If something wrote that file once, it can do it again.
The first thing I check is the timestamp on the file. That gives me a precise point in time to work from and becomes the anchor for everything that follows.
stat Stained_Heart_Red-600x500.png
This returns details about when the file was last modified and changed. Those timestamps are important because they tell me exactly when something wrote that file to disk.
Modify: 2026-03-24 02:13:45 Change: 2026-03-24 02:13:45 Access: 2026-03-24 02:13:45
I use that time as a reference point and build a timeline around it. Instead of guessing where the infection came from, I look at what was happening on the server within a small window before and after that timestamp.
That timestamp gets reused in the next steps. I check access logs for activity at that time, scan for other files modified within the same window, and look for any user or system activity that lines up with it. When multiple events cluster around the same time, it usually reveals how the file was created.
This approach turns the investigation into something structured instead of random searching. Instead of checking everything, I narrow it down to a specific moment and follow the activity from there. In most cases, that is where the entry point starts to show itself.
Tracing Activity in Logs
Once I have a timestamp from the file, I move straight to the web server logs and look at what was happening around that exact time. This is where things usually start to come together.
grep "24/Mar/2026:02:13" /var/log/httpd/access_log
This pulls requests that hit the server at the same time the file was created. On busy systems, I usually expand the window slightly by searching a few minutes before and after that time to avoid missing anything.
What I am looking for here is not just any request, but patterns that suggest something was uploaded or executed. POST requests are the first thing that stand out because they are commonly used for file uploads and form submissions.
Here is an example of what a suspicious entry might look like:
192.168.1.45 - - [24/Mar/2026:02:13:44 -0400] "POST /wp-admin/admin-ajax.php HTTP/1.1" 200 5321 "-" "Mozilla/5.0"
A request like this by itself is not proof of anything, but if it lines up exactly with the timestamp of the file you found, it becomes much more interesting. If that request is immediately followed by the appearance of a new file in the uploads directory, that is a strong indicator of how it got there.
I also look for requests hitting unusual paths or unknown PHP files. Anything outside of normal WordPress behavior stands out quickly once you know what the site typically does. Requests to files that should not exist are often tied directly to web shells or upload handlers.
It is also worth checking the error logs at the same time. Sometimes failed execution attempts, warnings, or permission issues will show up there and provide additional clues.
grep "24/Mar/2026:02:13" /var/log/httpd/error_log
I treat this step as part of building a timeline. The goal is not just to find a suspicious request, but to connect that request to the moment the file was written. When the timing lines up, it usually points directly to the entry point.
Checking for Other Modified Files
Malware rarely shows up as a single file. If one file was written, something else was usually modified around the same time. That is why I do not stop after finding one suspicious file. I expand the search to everything that changed within the same window.
find /home/user/public_html -type f -mmin -60
This shows files modified in the last 60 minutes. I adjust that window based on the timestamp I pulled earlier so it lines up with when the suspicious file appeared.
What I am looking for here is grouping. If several files were modified within seconds or minutes of each other, that is usually not normal activity. Legitimate changes tend to be spread out, while automated or malicious actions often happen in bursts.
Some of the things that stand out quickly are unexpected PHP files, modified plugin or theme files, or anything inside directories like wp-includes or wp-admin that should not change under normal conditions. Even a single file in the wrong place can point to a larger issue.
When I find multiple files with similar timestamps, I treat them as part of the same event. Instead of analyzing each one in isolation, I look at them together and trace them back to what was happening on the server at that moment. This is where the timeline from earlier steps becomes useful.
This step helps confirm whether the infection was isolated or part of a broader change. If everything lines up around the same time, it usually leads back to the same entry point you are trying to identify.
Verifying WordPress Users
Compromised admin accounts are one of the most common ways malware gets onto a WordPress site. If someone gets into the dashboard with a real account, they may be able to upload files, install plugins, edit theme files, or create new administrator users without setting off immediate alarms. That is why I always check the user list when I am tracing an infection.
The quickest way to do that is by reviewing the WordPress users table directly in the database. You can run this in phpMyAdmin, the MySQL command line, or any database tool you normally use to manage the site. The goal is not just to list users, but to see whether any accounts were added recently that you do not recognize.
SELECT ID, user_login, user_email, user_registered FROM wp_users ORDER BY user_registered DESC;
This query pulls the user ID, username, email address, and registration date from the wp_users table, then sorts the results so the newest accounts appear first. On some sites the table prefix will not be wp_, so if your database uses something like abc_users instead, you will need to adjust the query to match. That is important because a lot of WordPress installs use custom prefixes.
What I am looking for here is anything that does not belong. A username I did not create, an unfamiliar email address, or an account registered close to the time the infection appeared all deserve a closer look. Even if the username seems harmless, the registration date can expose when an attacker added it.
The next step is checking whether any of those users have administrator privileges. WordPress stores roles and capabilities in the usermeta table, so a second query can help confirm whether a suspicious account has elevated access. If I find an unknown account with administrator rights, I treat that as a likely entry point until proven otherwise.
SELECT u.ID, u.user_login, u.user_email, um.meta_value FROM wp_users u JOIN wp_usermeta um ON u.ID = um.user_id WHERE um.meta_key = 'wp_capabilities' ORDER BY u.ID DESC;
This query joins the main users table with the metadata table and shows the stored capabilities for each account. In the results, you will usually see values that indicate roles like administrator, editor, author, or subscriber. If your site uses a custom table prefix, you will need to change both wp_users and wp_usermeta, and also update wp_capabilities to match that prefix.
I do not stop at just identifying suspicious users. I also reset passwords for all administrators, review login activity if it is available, and remove any account I cannot verify. If a malicious user was added through the dashboard, cleaning files without removing that access just gives the attacker a way back in.
Searching for Hidden Web Shells
Sometimes the image file is not the entry point, it is just where the payload is stored. In a lot of cases, there is a separate PHP file somewhere on the server that acts as the control point. That file is what actually executes commands, uploads files, or communicates back to the attacker.
These are commonly referred to as web shells. They are usually small, easy to miss, and often obfuscated so they do not stand out at a glance. I have found them hidden in plugin directories, theme folders, and sometimes even inside core WordPress files.
The quickest way I check for these is by searching for functions that are commonly used to execute or decode malicious code.
grep -R "eval(" /home/user/public_htmlgrep -R "shell_exec" /home/user/public_html
grep -R "gzinflate" /home/user/public_html
These functions are not automatically malicious, but they are rarely used in normal WordPress code. When I see them, I open the file and inspect how they are being used. If the code is heavily obfuscated, dynamically decoding content, or pulling data from external sources, that is usually a red flag.
One thing I pay attention to is where the match is located. If it shows up inside a known plugin or library, I verify whether that usage is expected. If it appears in a random file inside the uploads directory or a theme folder where it does not belong, that is much more suspicious.
To reduce noise, I sometimes narrow the search to PHP files only.
find /home/user/public_html -type f -name "*.php" -exec grep -H -E "eval\(|shell_exec|gzinflate|base64_decode" {} \;This keeps the results focused on files that can actually execute code, which makes it easier to review.
I do not rely on a single keyword search. If something looks questionable, I read through the file and look for patterns like encoded strings, dynamically built function calls, or code that does not match the rest of the file. In most cases, once you see a real web shell, it stands out pretty quickly.
Checking Permissions and Cron Jobs
Permissions play a bigger role in this than most people expect. If directories are writable by the wrong user or have overly permissive settings, it becomes much easier for an attacker to drop files onto the system. Even if that was not the original entry point, weak permissions make it easier for malware to spread or persist.
I start by checking the uploads directory since that is where these files are usually found.
ls -la /home/user/public_html/wp-content/uploads
What I am looking for here is anything that stands out. Files or directories owned by the wrong user, or permissions that are too open, can be a problem. In most cases, directories should not be world writable, and files should not have permissions that allow everyone to modify them.
If permissions are too loose, I correct them as part of the cleanup. Even if the infection came from somewhere else, leaving those permissions unchanged makes it easier for it to happen again.
The next thing I check is whether anything is set up to reinstall the malware automatically. I have seen cases where everything was cleaned up, only for the same files to reappear because a scheduled task was putting them back.
crontab -l
I also check system-wide cron directories:
ls -la /etc/cron*
What I am looking for here is anything unexpected. Scripts running at regular intervals that I did not set up, commands that download or execute remote content, or anything referencing unknown files are all red flags.
If malware keeps coming back after cleanup, cron is one of the first places I look. A scheduled task can quietly restore files without any visible interaction, which makes it easy to miss if you are not checking for it directly.
Preventing It From Happening Again
Cleaning up the files is only part of the job. If the entry point is still open, the same problem can come back at any time. After I remove anything suspicious, I focus on closing the gaps that allowed it to happen in the first place.
One of the first things I do is block PHP execution in the uploads directory. That removes a major attack path because even if a malicious file is uploaded, it cannot be executed by the server.
If you are using Apache, you can do this directly in a .htaccess file inside the uploads directory:
<FilesMatch "\.php$">
Deny from all
</FilesMatch>This prevents any PHP file in that directory from being executed. Even if a malicious file gets uploaded, it will not run.
On some server configurations, you may also want to explicitly disable the PHP engine:
php_flag engine off
This adds another layer by preventing PHP from being processed in that directory at all.
I also take a closer look at how files are being uploaded in the first place. Any plugin or feature that allows uploads needs to validate file types properly and should not rely on file extensions alone. MIME type checking and server-side validation are important because attackers will often disguise files to bypass simple checks.
I also remove anything I do not need. Old plugins, unused themes, and leftover files increase the attack surface and make it easier for vulnerabilities to go unnoticed. Keeping the environment minimal makes it easier to monitor and maintain.
Finally, I make sure everything is up to date. WordPress core, plugins, and themes should all be running current versions. Many of these attacks rely on known vulnerabilities that have already been patched, so staying updated closes off those entry points.
The goal is not just to clean up the current issue, but to make it harder for the same type of attack to succeed again.
Monitoring for Reinfection
After everything is cleaned up, I do not assume the problem is solved. If the original entry point is still open, the same type of file can show up again. That is why I keep an eye on the uploads directory for a while after cleanup.
One of the simplest ways to do that is by watching file activity in real time. On most systems, this can be done using inotifywait.
inotifywait -m /home/user/public_html/wp-content/uploads
If the command is not available, you can install it using the inotify-tools package.
dnf install inotify-tools -y
or on Debian-based systems:
apt install inotify-tools -y
Once running, this will print events as they happen, including file creation, modification, and deletion. On a normal site, you will only see activity when media is uploaded or updated through the dashboard. That kind of activity is predictable and tied to user actions.
What I am watching for is anything that does not match that pattern. Files appearing without a corresponding upload, changes happening at unusual times, or repeated activity from automated processes are all signs that something may still be wrong.
If I see a file being created that I did not expect, I check it immediately. I look at its contents, check its timestamp, and then trace it back using the same steps from earlier. Catching it as it happens makes it much easier to identify the source.
I also pay attention to repeated behavior. If the same type of file keeps appearing or shows up at regular intervals, that usually points to something automated like a script or scheduled task. That kind of pattern is often easier to spot through monitoring than through one-time scans.
If you do not want to install additional tools, you can still monitor changes with a simple loop.
watch -n 2 "ls -lt /home/user/public_html/wp-content/uploads | head"
This is not real-time, but it will show recently modified files and can still help you catch unexpected activity.
If nothing unexpected shows up over time, that is a good sign that the entry point has been closed. If something does appear, you have a chance to catch it early and trace it before it spreads
Final Thoughts
Hidden malware inside image files blends into one of the busiest directories on a WordPress site. It does not rely on obvious signs and often stays in place longer than expected because it looks like something that belongs there.
What makes the difference is not just finding the file, but understanding how it got there. Once you start working from timestamps, logs, and related file changes, the investigation becomes structured instead of guesswork. That is usually where the real entry point shows up.
Cleaning it up is only part of the process. Locking down execution paths, tightening uploads, and watching for new activity are what prevent the same issue from coming back. If nothing unexpected shows up after that, you know the problem is actually resolved.
