Samsung MagicInfo Server Compromised? How to Find and Clean Rogue JSP Web Shells

I was going through the folders of a Samsung MagicInfo Premium server recently and something looked wrong straight away. The server folder was full of .jsp files with random names like kYNUTDVHqYp.jsp and BoBTaexeKzv.jsp, a stray magicinf.php (on a Java application!), and a couple of extensionless files that Windows showed as “Microsoft Edge HTML”. The installed version, checked in Programs and Features, was MagicInfo 21.1040.2.

If you see the same pattern, do not just delete the files and move on. This post explains what is probably going on, how to confirm it, and how to clean up properly.

Why random JSP files are a red flag

MagicInfo 9 Server runs on Java and Tomcat. A normal install has a fixed set of JSP pages that ship with the product. Files with random 8 to 12 letter names, created on dates when nobody deployed anything, do not belong there. The usual explanation is a web shell: a small JSP page an attacker uploads so they can run commands on the server through a browser.

In this case it turned out to be a full compromise, not just a few stray files. Here is what the attacker actually did, because the JSP files were only the first step.

What the attacker did on this server

1. Uploaded JSP web shells into the MagicInfo web folder, using the unpatched upload flaw. That gave them command execution on the server.
2. Created a scheduled task so the malware would keep coming back after a reboot or after a file was deleted.
3. Added Microsoft Defender exclusions for the Downloads folder, a system user profile folder, the Temp folder and a few others. This is the clever and dangerous part: Defender no longer scans those paths, so the payloads can sit there untouched.
4. Created Windows services as a second persistence method. A service starts at boot with high privileges and is easy to overlook next to the real ones.
5. Added registry entries for persistence, so the malware would also start whenever the machine booted or a user logged on.
6. Installed a crypto miner. The server’s CPU was being used to mine cryptocurrency for the attacker.
7. Left malware running in memory. A full disk scan showed nothing wrong, but the Kaspersky Virus Removal Tool and the Emsisoft Emergency Kit both found an infection in memory.

This is a very common pattern for exploited, internet-facing servers: get in through a vulnerability, switch off the antivirus by adding exclusions, set up persistence, then run a miner. If you only delete the JSP files, the scheduled task simply downloads the miner again.

The vulnerabilities behind it

• CVE-2024-7399: a path traversal flaw in MagicINFO 9 Server that lets an unauthenticated attacker write arbitrary files with system privileges. Samsung fixed it in 21.1050. Arctic Wolf reported active exploitation in May 2025, where attackers uploaded a .jsp file and then ran OS commands through it. A Mirai botnet variant was also reported using it.
• CVE-2025-4632: a related path traversal in the SWUpdateFileUploader servlet, rated CVSS 9.8. Public proof-of-concept code worked on systems already patched for CVE-2024-7399, so it looks like a patch bypass. Versions before 21.1052 are affected, and 21.1052.0 fixes it. CISA added it to its Known Exploited Vulnerabilities list on 22 May 2025.

Version 21.1040.2 is older than both fixes, so it is exposed to both problems.

The attack from the attacker’s point of view

To defend a server well, it helps to think like the person attacking it. I am not going to publish exploit code, and you do not need it. What matters is understanding why each step happened, because every step is also a chance to catch the attacker. This is the kill chain I reconstructed from what I found on the server.

Stage 1: Finding the target

Attackers do not pick a company. They scan the whole internet for a specific product, often with search engines such as Shodan or Censys, or with their own scanners. A MagicInfo server is easy to recognise because its login page and a configuration file reveal the product and its version. When the CVE-2025-4632 advisory came out, Censys counted over 1,100 MagicInfo servers exposed to the internet. Once a public proof-of-concept exists, scripts try it against every one of them automatically. Nobody looked at this server in particular. It was simply reachable and unpatched.

Where you could have stopped it: keep the server off the public internet, and patch within days of an advisory, not months.

Stage 2: Initial access through the upload flaw

The vulnerable upload servlet accepted a file from an unauthenticated visitor and did not properly check where the file name pointed. By including directory traversal in the name, the attacker made the server write the file outside the intended upload folder, straight into the web-accessible folder. No password, no phishing, no stolen account was needed. In MITRE ATT&CK terms this is Exploit Public-Facing Application (T1190).

Where you could have caught it: a POST request to the uploader servlet from an address that is not one of your own, in the Tomcat access log.

Stage 3: Web shell for a foothold

The uploaded file was a JSP page. Visiting it in a browser runs whatever command is passed to it, and the output appears on the page. This is a web shell (T1505.003). Attackers like it for three reasons: it is tiny, it works over normal HTTP so a firewall sees ordinary web traffic, and it runs with the rights of the MagicInfo service, which here meant system-level access. The random file names are deliberate. They stop defenders searching for a known name and they stop other attackers from finding and reusing the shell.

Several JSP files with different dates are also telling. They usually mean one of two things: more than one attacker used the same hole, or one attacker uploaded fresh copies after a clean-up. Either way, the server was visited repeatedly over weeks.

Where you could have caught it: a file-integrity alert on new .jsp files in the web folder, or an outbound connection from the Java process.

Stage 4: Switching off the defences

The first thing a careful attacker does with command execution is make sure the antivirus cannot interfere. Instead of turning Defender off, which is noisy and shows a warning, they add exclusions for folders such as Downloads, Temp and a user profile (T1562.001). This is quieter, it survives reboots, and the product still reports “protection on”. Everything the attacker later drops into those folders is invisible to scheduled and real-time scans.

Where you could have caught it: Defender logs an event when its configuration changes (event ID 5007 in the Windows Defender Operational log). An alert on any new exclusion would have caught this on day one.

Stage 5: Payload and persistence, in layers

Next the attacker downloaded the miner and set up several ways to keep it alive. Using more than one is deliberate. A defender who removes one still leaves the others:

• Scheduled task (T1053.005): re-runs the download or the miner on a timer, so a deleted file simply comes back.
• Windows services (T1543.003): start at boot, run as SYSTEM, and the names are often chosen to look like real services. On this server there were several duplicate miner services, which watch and restart each other, so removing a single one achieves nothing.
• Registry Run keys (T1547.001): starts the malware when the machine boots or a user logs on.
• Memory-resident code: the payload is loaded straight into a running process, so no file on disk needs to exist. This is why the disk scan looked clean while the Kaspersky and Emsisoft memory scans still found it.

The layers also work as a safety net for the attacker against exactly what you did: deleting the web shells and the visible files. Removing the JSP files cut the front door, but the scheduled task, service and registry entries were the back doors.

Where you could have caught it: events 4698 (task created), 7045 and 4697 (service installed), and registry auditing on the Run keys.

Stage 6: Monetising with a crypto miner

The goal in this case was money. A cryptominer (T1496, Resource Hijacking) turns your CPU and electricity into cryptocurrency for the attacker. It is a popular choice because it needs no victim interaction, produces income immediately and is low risk. For the owner it means a slow server, high power use, shorter hardware life and a machine that is controlled by a stranger.

Do not treat a miner as harmless. The access that installed the miner could just as easily have installed ransomware, stolen the database or used the server to attack the rest of your network. Miners are often the cheapest, loudest payload from an attacker who already holds a doorway that can be sold or reused. In the Mirai case reported for this same flaw, the doorway was used to build a botnet instead.

Stage 7: Staying hidden

Attackers also try to remain unnoticed. They limit the miner’s CPU use so the server does not look obviously slow, name processes and services after legitimate ones, keep payloads inside excluded folders, and delete their own logs and temporary files.

On this server the Windows Event Viewer had gaps: whole time periods with no entries at all. That is a technique called Clear Windows Event Logs (T1070.001). It is not a coincidence. The attacker cleared the logs to hide what they did, which means the missing period is usually the most interesting one. A gap in your logs is evidence of tampering, not evidence that nothing happened.

How to confirm the logs were cleared

Clearing a log writes its own record, unless the attacker also deleted that. Look for these events:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=1102} -ErrorAction SilentlyContinue |
  Select-Object TimeCreated, Message
Get-WinEvent -FilterHashtable @{LogName='System'; Id=104} -ErrorAction SilentlyContinue |
  Select-Object TimeCreated, Message

Event 1102 means the Security log was cleared and 104 means another log (such as System) was cleared. Both record the account that did it and the time. If neither event exists but there is a clear gap, the log may have been cleared in another way, for example by stopping the Event Log service or deleting the .evtx files, which is still a sign of an attacker with administrator rights.

Where else to look when the Event Viewer is incomplete

• Defender logs and history: Microsoft-Windows-Windows Defender/Operational and the quarantine and detection history under C:\ProgramData\Microsoft\Windows Defender. These are separate files and are often missed.
• PowerShell logs: the Microsoft-Windows-PowerShell/Operational log (event 4104) and the console history file at %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt.
• Application and web logs: the Tomcat access and error logs, which a Windows log clear does not touch.
• Network logs: the firewall, router or ISP logs, which the attacker cannot reach from the server.
• Program-execution artifacts: Prefetch (C:\Windows\Prefetch), Amcache and ShimCache show what ran and roughly when, even if the event logs are gone.
• File system: the file creation and modified times of the JSP files, scheduled task files in C:\Windows\System32\Tasks and service registry keys, which give you a timeline that does not depend on the Event Viewer.
• Backups and snapshots: a Veeam backup, VM snapshot or restore point from before the attack still holds the original logs. Mount it read-only and compare.

The lesson is to ship logs to a separate machine (a syslog server, a SIEM or even a second Windows server using Windows Event Forwarding) while the server is still healthy. An attacker who owns the server can erase its local logs, but cannot reach copies that were already sent somewhere else.

Timeline at a glance

Stage	What the attacker does	ATT&CK technique	What defenders can see
Initial access	Unauthenticated upload that writes a JSP file	T1190	POST to the uploader servlet in the Tomcat log
Foothold	JSP web shell, random file names	T1505.003	New .jsp files, odd GET requests with a command parameter
Defence evasion	Defender exclusions for Downloads, Temp, user folders	T1562.001	Defender event 5007, exclusion list not empty
Persistence	Scheduled task, Windows service, registry Run keys	T1053.005, T1543.003, T1547.001	Events 4698, 7045, 4697, new autorun entries
Execution in memory	Payload loaded into a running process	T1055	Memory scan, unusual process behaviour
Cover-up	Clears event logs, leaving gaps	T1070.001	Events 1102 and 104, gaps in the Event Viewer timeline
Impact	Crypto miner	T1496	Constant high CPU, connection to a mining pool

What this means for defenders

1. The attacker needed one unpatched, internet-facing flaw. You need to close every such door, which is why patching speed and reducing exposure matter more than any single tool.
2. Antivirus exclusions are a favourite target. Alert on any change to them.
3. Persistence is layered. When you clean up, find all of the layers or the malware returns.
4. A clean disk scan does not mean a clean machine. Memory and persistence both need checking.
5. Logs are your evidence. Send them to another machine so an attacker on the server cannot erase them.

Step 1: Isolate the server, but do not wipe it yet

Pull the server off the internet first. Block inbound access at the firewall, or remove the public NAT rule if MagicInfo is exposed. Do not power it off or delete anything yet. You want the files, logs and running state as evidence, because the web shell is only the part you can see.

Copy the whole MagicInfo folder and the Tomcat logs to a safe location before touching anything.

Step 2: List what was added and when

This PowerShell command lists every JSP, JSPX and PHP file under the MagicInfo folder, newest first. Change the path to your install location:

Get-ChildItem "D:\Magicinfo" -Recurse -Include *.jsp,*.jspx,*.php -ErrorAction SilentlyContinue |
  Sort-Object LastWriteTime -Descending |
  Select-Object FullName, Length, LastWriteTime -First 50

What this does: it walks every sub-folder, keeps only script files, sorts by last modified time and prints the path, size and date. Files that sit in the product folders but were modified long after your install date are your first suspects. Small files (1 to 8 KB) with random names are typical for web shells.

Step 3: Look inside the suspicious files

Open them in a text editor, never in a browser. Do not request them over HTTP, because that can execute them. A quick search for code that runs system commands:

Get-ChildItem "D:\Magicinfo" -Recurse -Include *.jsp,*.jspx -ErrorAction SilentlyContinue |
  Select-String -Pattern "Runtime.getRuntime","ProcessBuilder","getParameter\(.cmd" |
  Select-Object Path, LineNumber

Any hit in a file you do not recognise is a strong sign of a web shell. Legitimate pages rarely call Runtime.getRuntime().exec with a request parameter.

Step 4: Find out how they got in and what they did

Check the Tomcat access logs (the path depends on your install) for requests to the uploader servlet and then to the new files:

Select-String -Path "D:\Magicinfo\*\logs\*access*" -Pattern "SWUpdateFileUploader|\.jsp" |
  Select-Object -First 100

A POST to SWUpdateFileUploader followed by a GET to a random-named JSP is the attack pattern. The log dates also tell you how long the attacker had access. Then check for persistence, because a web shell is usually just the start:

Get-LocalUser | Select Name, Enabled, LastLogon
Get-ScheduledTask | Where-Object State -ne 'Disabled' | Select TaskName, TaskPath
Get-CimInstance Win32_Service | Where-Object PathName -notlike '*Windows*' | Select Name, PathName, StartName
Get-NetTCPConnection -State Established | Select RemoteAddress, RemotePort, OwningProcess

Look for new local accounts, scheduled tasks or services you did not create, and outbound connections from the Java process to unknown addresses. On Windows Server you should also review the Security log for event 4720 (account created) and 4624 (logons) around the file dates.

Step 4b: Check Defender exclusions, scheduled tasks, services, registry and the miner

These are the things that were abused here. Check them before you run any scan, because a scanner that respects Defender exclusions will skip exactly the folders the attacker hid things in.

1. Defender exclusions. List every path, process and extension that Defender has been told to ignore:

Get-MpPreference | Select-Object ExclusionPath, ExclusionProcess, ExclusionExtension

On a normal server this list is empty or contains only things you added on purpose. Exclusions for Downloads, Temp, user profile folders or the whole C:\Users tree are a classic sign of an attacker. To remove one (run PowerShell as administrator):

Remove-MpPreference -ExclusionPath "C:\Windows\Temp"

Write down the full list first, so you can show it in your incident report. Also check Get-MpComputerStatus to make sure real-time protection is still on, because some attackers disable it completely.

2. Scheduled tasks. Show every task together with the command it runs, which is the part that matters:

Get-ScheduledTask | Where-Object { $_.TaskPath -notlike '\Microsoft\*' } |
  Select-Object TaskName, TaskPath, State,
    @{n='Run';e={($_.Actions | ForEach-Object { $_.Execute + ' ' + $_.Arguments }) -join '; '}}

What this does: it hides the built-in Microsoft tasks and prints the program and arguments each remaining task launches. Look for tasks that run PowerShell with encoded commands, mshta, certutil, curl or wget, or anything pointing into Temp, Downloads or a user folder. Export the task XML as evidence (Export-ScheduledTask -TaskName "name") before you remove it with Unregister-ScheduledTask.

3. Windows services. The attacker also created services, so list every service that does not live in the Windows folder, with the account it runs as:

Get-CimInstance Win32_Service |
  Where-Object { $_.PathName -notlike '*\Windows\*' -and $_.PathName -notlike '*Program Files*' } |
  Select-Object Name, DisplayName, State, StartMode, StartName, PathName

What this does: it prints each service with its start mode, the account it runs under and the exact file it launches, after filtering out the usual Windows and Program Files locations. Be suspicious of random or look-alike names, services with StartName set to LocalSystem that point into Temp, Downloads, ProgramData or a user profile, and any service you cannot trace to installed software. Save the details, then stop and remove it:

Stop-Service -Name "ServiceName" -Force
sc.exe delete "ServiceName"

Expect duplicates. On this server I did not find one miner service but several, with similar settings and different names. This is deliberate. The copies act as watchdogs for each other: if you stop or delete one, another notices and starts it again, or reinstalls it. To get rid of them reliably:

1. List all of them first and note every PathName. Do not remove one at a time and then re-check.
2. Set them all to disabled before stopping any (Set-Service -Name "ServiceName" -StartupType Disabled), so nothing can restart them.
3. Look at each service’s recovery options (sc.exe qfailure "ServiceName"). Attackers often set “restart on failure” so a killed service comes straight back.
4. Stop the services and kill the matching processes (Stop-Process -Id <PID> -Force), then delete the service entries with sc.exe delete.
5. Delete the files each PathName pointed to, after saving a copy and its hash (Get-FileHash) for evidence.
6. Reboot and run the same list again. Anything that returns means a scheduled task, registry entry or another service is still reinstalling it.

Also check the Security log for event 4697 and the System log for event 7045. Both are written when a new service is installed, so they give you the exact time and the account that did it.

4. Registry entries. Attackers also hide persistence in the registry. Check the usual autorun locations:

$keys = 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Run',
        'HKLM:\Software\Microsoft\Windows\CurrentVersion\RunOnce',
        'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run',
        'HKCU:\Software\Microsoft\Windows\CurrentVersion\RunOnce',
        'HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Run'
foreach ($k in $keys) { "--- $k"; Get-ItemProperty $k -ErrorAction SilentlyContinue }

What this does: it prints every program set to start automatically from the Run and RunOnce keys, for the machine and for the current user. Any entry pointing to Temp, Downloads, ProgramData or a user profile folder, or one that runs PowerShell, mshta or rundll32 with odd arguments, needs investigating.

Three more places worth checking:

• Defender settings in the registry: HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths (and the same under Policies). Exclusions added by an attacker are stored here too, and you can see them even if Defender itself is tampered with.
• Services: HKLM\SYSTEM\CurrentControlSet\Services. Each service the attacker created has a key here with an ImagePath value showing the file it runs.
• Winlogon and IFEO: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon (look at Shell and Userinit) and Image File Execution Options, which attackers use to hijack programs.

Export a key before changing it (reg export "HKLM\...\Run" run-backup.reg), so you keep the evidence, then delete only the entries you have confirmed are malicious. Sysinternals Autoruns is a good free tool for seeing all of these locations, tasks and services in one view.

5. The miner. Miners show up as one process that uses a lot of CPU all the time:

Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 Name, Id, CPU, Path

A process with no path, a random name, or a path inside Temp or Downloads is suspicious. Check which remote address it talks to with Get-NetTCPConnection -OwningProcess <PID>. Miners usually connect to a mining pool on ports like 3333, 4444, 5555 or 14444.

Step 4c: Scan memory, not only the disk

This is where the disk scan misled me. Everything looked clean on disk, but the malware was running in memory. Two free tools found it:

• Kaspersky Virus Removal Tool
• Emsisoft Emergency Kit

Run them as administrator, tick the option to scan running processes and memory, and use more than one tool, since each one finds different things. They are good for finding and confirming an infection. They are not proof that the server is clean afterwards, because a clean scan result does not show that the scheduled tasks, accounts and leftover backdoors are gone.

Step 5: Clean up the right way

Removing the JSP files alone is not enough. Because the attacker could run commands with system privileges, I would not trust this machine again. My recommended order:

1. Rebuild the server from a clean OS image if you can. This is the only way to be sure nothing is left behind.
2. Install MagicInfo again from Samsung’s official download, version 21.1052.0 or later, and restore your content and database from a backup taken before the first suspicious file date.
3. Rotate every credential the server knew: MagicInfo admin accounts, the database user (these installs often bundle PostgreSQL), Windows local and service accounts, and any API keys stored on it.
4. If a rebuild is not possible right away, at least delete the confirmed web shells, apply the patch, and keep the server isolated while you finish checking for persistence.

Step 6: Stop it happening again

• Do not expose MagicInfo to the internet. Put it behind a VPN or restrict access to your management network. Researchers found over a thousand internet-facing MagicInfo servers when the second CVE was disclosed.
• Patch promptly. Both flaws were exploited within days of public proof-of-concept code.
• Watch the file system. A scheduled script that alerts on new .jsp files in the web folder would have caught this early.
• Check your displays. The Mirai activity targeted devices, so confirm the connected screens are healthy too.

Quick checklist

1. Note the installed version (Programs and Features). Anything below 21.1052 is vulnerable.
2. Isolate the server and copy files and logs for evidence.
3. List recent JSP, JSPX and PHP files and search them for command execution.
4. Check access logs, accounts, tasks, services and outbound connections.
5. Rebuild, upgrade to 21.1052.0 or later, restore clean data, rotate credentials.
6. Take the server off the public internet.

Have you found web shells on a digital signage or other IoT management server? Tell me what you saw in the comments and I will add it here.

Sources: BleepingComputer, Samsung MagicINFO 9 Server RCE flaw now exploited; Censys advisory on CVE-2025-4632; Help Net Security on CVE-2024-7399; SentinelOne vulnerability database.