A library catalog is supposed to help readers find books, journals, and other academic resources. At IAIN Parepare, our security team’s investigation records show a very different picture: injected gambling-related pages, unexpected changes to application files, and occasions when the catalog returned to the SLiMS installation screen.
The visible symptoms were only part of the problem. Behind them were suspicious PHP files, altered configuration, administrator access concerns, and requests to endpoints that should never have been exposed to routine internet traffic. The central question for our team was not simply how to remove the unwanted page. It was how an attacker had gained the ability to keep changing the system.
A July 2026 screenshot captured unauthorized gambling-related content under the catalog domain. The advertisement and third-party page details are concealed here; the source screenshot is retained in the internal record.
Table of Contents
Our investigation began with various evidences
The incident notes span reviews in late February, March, April, July, and August 2026. We compared application files against known-good copies, examined file modification times, and correlated suspicious requests with their source IPs, timestamps, HTTP methods, and accessed endpoints. Those checks helped separate what the logs actually proved from what still needed validation.
One early review linked a modified PHP library file to a backdoor and documented a suspicious plugin-management file accessible without normal authentication. Another review found malicious PHP in directories ordinarily used for images, fonts, or other static assets. These locations mattered because a superficial scan of the homepage would not reveal a concealed web shell elsewhere in the file tree.
A cropped view of the team’s log-analysis dashboard. The time-series display is preserved; raw request bodies and infrastructure identifiers are excluded.
This is an important distinction in incident response: a timestamp on a file may indicate when a change occurred, but it does not by itself prove who made it or which vulnerability was used. We used the surrounding access logs and file comparison work to build a more reliable attack narrative.
Finding 1. Injected index.php file
In the February review, our team identified malicious code inserted into the site’s index.php file. The code attempted to retrieve content from an external location, and the incident record associated it with gambling-related links displayed through the library website. We also documented a suspicious plugin file and restored a modified application library file from an original copy.
The investigation extended beyond that single entry point. Multiple hidden PHP files had appeared in unexpected folders. We reviewed these artifacts as potential persistence mechanisms—ways for an attacker to return after the visible injection had been removed.
Our response: We removed the injected code and suspicious plugin, compared the running application with a clean source, restored confirmed altered files, and performed additional manual malware checks.
The February–March record labels that remediation round as resolved. Later incidents show why that status must be read as a point-in-time result, not a guarantee that the wider system was permanently secure.
Finding 2. An installation endpoint remained an attack path
In March, the team investigated why the SLiMS site had returned to an installation state. Requests to the installer API were associated with configuration changes. The recorded response was to disable access to the installer endpoint and restore the database so the public catalog could run again.
The SLiMS installation screen documented during the March incident, when the application was no longer presenting its normal library catalog.
The same general risk resurfaced in the 20 August review. Our team documented repeated requests to the installer API and a modified database configuration pointing to an external database host. That incident is recorded as a confirmed compromise. The notes describe making the configuration file read-only as a mitigation; other steps—including installer removal, broader credential rotation, and firewall blocks—are listed as recommended actions rather than verified completed work.
This recurrence changed how we framed the problem. Restoring a working catalog was essential, but the installer itself had to be treated as a security-sensitive surface. A service can be brought back online and still retain the path that allowed an attacker to interfere with it.
The public-facing library catalog shown after the March database restoration. This establishes a documented recovery milestone, not proof of long-term absence of compromise.
Finding 3. Administrator access and configuration controls mattered
The April review documented malicious edits to a PHP environment-configuration file. Our team recreated the behavior and noted that the dangerous change was possible when the application was operating in development mode; the same reproduction did not succeed in the production-mode configuration shown in the record. The notes also indicate that the exploit path required administrator access.
Malware Hunter AI quarantined an altered configuration file in April. The actual server IP, host identifier, and absolute file path have been redacted.
We reviewed user and administrator access, identified weak credential practices, and documented password changes. The team also disabled plugin management in a sensitive administrative route and reviewed login error messages that differentiated between invalid usernames and wrong passwords, a condition that can make account enumeration easier.
Our response: We treated credential hygiene, access restrictions, and production-safe settings as part of the incident fix—not as optional follow-up tasks.
Finding 4. The OAI endpoint exposed a deeper SQL injection risk
The most technically significant finding in the August notes concerned the catalog’s OAI endpoint. On 2 August, the team traced crafted requests involving a resumption token and found SQL statements embedded in the supplied values. The incident record links the technique to changes targeting an administrator account, alongside security alerts for malicious file modifications and creation.
Rather than relying only on blocking the source address, our team patched the token-handling logic. The documented change added an HMAC-SHA256 signature to server-issued OAI resumption tokens and rejected modified tokens before their query state could be used. The team also recorded an administrator password change and a CrowdSec block for the observed source IP.
A cropped access-log time series from the 2 August investigation. Detailed request strings—including encoded SQL payloads—have been excluded from the publication copy.
This fix matters because a token can look like ordinary application state while carrying fields that should not be trusted simply because they arrived in a request. Signing tokens creates an integrity check: if a client changes the token after issuance, the server can reject it. It addresses the specific tampering path documented in the incident; it is not a substitute for safe database queries and broader endpoint security testing.
Malware removal was only one part of the work
The response records include malware-scanner tuning and infrastructure hardening alongside application-level repairs. In one review, the team found that the scanning configuration covered too much data, causing the watch process to struggle. The notes describe narrowing the watched paths and following up with manual scans. They also record suspicious obfuscated code that had not been caught by the existing scanning workflow.
The team fixed a CrowdSec misconfiguration, installed Snuffleupagus as an added PHP security control, cleaned up residual backdoors, and reviewed suspicious file changes and unauthorized administrative activity. These measures belong together: a stronger server configuration may reduce exposure, but it cannot replace identifying the vulnerable application endpoint or removing an attacker’s existing foothold.
What our team did, and what the records confirm
| Area | Documented action / evidence |
| Malicious files | Injected code and suspicious plugin removed; known altered file restored; additional backdoors reviewed and cleaned. |
| Installer access | Installer API disabled and database restored in March; renewed exploitation confirmed in August. |
| Account controls | Administrator password changes and access restrictions documented during multiple response rounds. |
| OAI endpoint | HMAC-SHA256 token-signing and verification patch recorded; attacker source blocked in CrowdSec. |
| Detection & hardening | YARA quarantine alerts, manual source comparisons, scanner configuration changes, CrowdSec correction, and Snuffleupagus installation recorded. |
There were concrete improvements. A March restoration brought back a normal catalog page. The February remediation round was marked resolved in the source notes. April detections show suspicious PHP files being quarantined. The August investigation produced a focused OAI token-integrity patch, a recorded administrator credential change, and an IP block.
But this was a recurring case. A July content injection and an August installer-related compromise appear after earlier recovery actions. The available records do not establish a final, independently verified clean bill of health after the last August incident, a measured reduction in attack volume, or a specific uptime figure. Claiming any of those would be stronger than the evidence allows.
For our team, the more useful outcome is the documented progression from visible symptom removal to understanding distinct attack paths, preserving evidence, and applying targeted countermeasures. The incident notes also make clear that remediation and verification must continue when an environment has been compromised more than once.
What this case teaches other SLiMS administrators
A compromised SLiMS website may look like a content problem, but the underlying issue can involve far more than the page visitors see. Old installer components, unrestricted administrative features, altered configuration files, weak accounts, vulnerable token handling, and ineffective malware coverage can each create opportunities for renewed compromise.
The best starting point is to preserve evidence, identify the exact altered files and requests, establish what has been confirmed, and then address the specific weakness. Replacing a page or deleting a web shell without tracing its entry point risks leaving the attacker’s access intact.
Conclusion
This case demonstrates that recovering a compromised SLiMS system requires more than simply removing malicious files. Attackers may exploit multiple weaknesses, maintain hidden backdoors, and find new ways to regain access even after an initial cleanup.
Throughout this investigation, our security team identified critical vulnerabilities, traced suspicious activities, removed malicious files, and implemented targeted security fixes to address the identified threats. From investigating unauthorized administrator access to securing vulnerable endpoints and improving malware detection, each finding helped us better understand the attack and strengthen the system’s defenses.
The experience also highlights an important lesson: website security is not a one-time fix. Regular monitoring, timely security updates, proper server configuration, and proactive vulnerability assessments are essential to keeping SLiMS applications secure and reliable.
Keep Your SLiMS System Secure with our Hosting and Security Services
Whether you manage an existing SLiMS installation or are planning to launch a new library system, having the right technical team makes a difference.
At Open Journal Theme (OJT), we provide SLiMS Hosting and Security Services to help institutions maintain secure, stable, and properly managed library systems. Our team combines hands-on experience in security incident investigation, malware removal, vulnerability remediation, and server management to help protect your library’s digital infrastructure.
