12 signs your backend has been compromised

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs CEH (Certified Ethical Hacker)

Why compromised backends stay compromised

The average time to detect a breach in financial services is 197 days. That is over six months of an attacker living inside your infrastructure, reading your database, intercepting transactions, and exfiltrating customer BVNs and NINs. In the Nigerian ecosystem, where NIBSS processed over ₦390 trillion in electronic payments in 2024, every day of undetected compromise translates directly into stolen funds and regulatory exposure under both the CBN Risk-Based Cybersecurity Framework and the Nigeria Data Protection Act (NDPA).

The reason detection takes so long is that most engineering teams do not know what to look for. They wait for customer complaints or a CBN inquiry. By then, the damage is catastrophic. The twelve signs below give you a concrete checklist to audit your systems right now. If you find even three of these indicators present, treat your environment as compromised until proven otherwise.

1. Unexplained database queries running at unusual hours

This is one of the earliest and most reliable indicators of compromise. Attackers who gain database access typically run bulk extraction queries during off-peak hours - between 1am and 5am local time - to minimize the chance of detection. The signature is unmistakable: SELECT * queries against your users, transactions, or wallets tables at times when no legitimate application process or batch job is scheduled.

What to check: Enable and review your database slow query log. In PostgreSQL, check pg_stat_activity for active queries and their start times. In MySQL, review the general query log or enable the Performance Schema. Look for full-table scans (SELECT * with no WHERE clause) against sensitive tables, especially outside business hours. Cross-reference query timestamps with your application deployment schedule and known cron jobs.

What it means: An attacker has obtained database credentials - likely from a leaked .env file, a compromised developer workstation, or an SQL injection vulnerability - and is exfiltrating your customer data in bulk.

Immediate action: Rotate all database credentials immediately. Restrict database access to application-layer service accounts only. Implement IP whitelisting on your database server. Enable audit logging and forward logs to an external SIEM that the attacker cannot tamper with.

2. API response times suddenly spiking

Your payment API consistently responds in 120ms. Then one day, without any deployment or traffic change, response times jump to 800ms or more. Your engineers check the code - nothing changed. They check the database - indexes are fine. They check the load balancer - traffic is normal.

What to check: Review your application process list for unfamiliar background processes. Check CPU and memory utilization at the OS level using tools like htop or your cloud provider's monitoring dashboard. Examine network throughput - is your server sending more outbound data than usual? Compare current response time baselines against the last 30 days in your APM tool (Datadog, New Relic, or even basic CloudWatch metrics).

What it means: Something is consuming resources on your server that should not be there. Common causes include cryptocurrency mining malware, active data exfiltration consuming bandwidth, or a reverse shell maintaining a persistent connection to the attacker's command-and-control server.

Immediate action: Identify and kill any rogue processes. Run a malware scan. Check for unauthorized scheduled tasks. If you find a mining process or reverse shell, assume full compromise and initiate your incident response plan.

3. Unknown SSH keys in authorized_keys

This is the digital equivalent of finding a stranger's house key on your keyring. Attackers who gain initial access to a server almost always plant an additional SSH key in the authorized_keys file to guarantee persistent re-entry, even if you change the password or patch the original vulnerability they exploited.

What to check: Open ~/.ssh/authorized_keys on every server in your fleet. Compare each key against your team's inventory of known developer keys. Check the file's modification timestamp. Also check /root/.ssh/authorized_keys if root login is enabled (it should not be). On Ubuntu and Debian, check /etc/ssh/sshd_config for AuthorizedKeysFile directives that may point to non-standard locations.

What it means: An attacker has established persistent backdoor access to your server. Even if you patch the vulnerability they used to get in, they can return anytime via this planted key.

Immediate action: Remove any unrecognized keys. Audit and rebuild the authorized_keys file from scratch using only verified team member keys. Disable password-based SSH authentication entirely. Implement centralized SSH key management. Consider rotating all server instances - rebuild from your infrastructure-as-code templates rather than trying to clean a potentially compromised image.

4. New admin or superuser accounts you did not create

Check your application's admin panel, your database user list, and your operating system user accounts. If you find an account with elevated privileges that nobody on your team created, you have a confirmed indicator of compromise.

What to check: On Linux, review /etc/passwd and /etc/shadow for new user entries - especially any with UID 0 (root equivalent). In your application database, query your users or admins table for accounts created in the last 90 days and verify each one with your team. Check your cloud provider's IAM console for roles or service accounts you do not recognize. In AWS, review the CloudTrail logs for CreateUser or AttachRolePolicy events.

What it means: The attacker has escalated privileges and created a persistent backdoor account. This is a high-severity indicator - it means they had enough access to create administrative users, which implies deep compromise.

Immediate action: Disable the rogue account immediately - do not delete it yet, as it is forensic evidence. Audit all recent actions performed by that account. Force a password reset for all legitimate admin accounts. Enable MFA on every administrative access point. Review your environment variable security to determine how the attacker obtained initial access.

5. Unusual outbound traffic to foreign IP addresses

Your fintech server should communicate with a predictable set of external services: your payment processor's API, your cloud provider's endpoints, your KYC verification partner. If your server is making connections to IP addresses in Eastern Europe, Southeast Asia, or anywhere your business has no legitimate relationship with, that is data leaving your network without authorization.

What to check: Use netstat or ss on Linux to list active network connections and their destinations. Cross-reference destination IPs against your known service provider list. Check your firewall or VPC flow logs for outbound connections on unusual ports (especially high-numbered ports above 8000 that are not part of your application stack). Use a threat intelligence service to look up any suspicious IPs.

What it means: Active data exfiltration or command-and-control communication. The attacker is either sending your stolen data to an external collection server or maintaining a persistent control channel.

Immediate action: Block the suspicious IPs at your firewall immediately. Implement strict egress filtering - your servers should only be able to communicate with explicitly whitelisted external services. Capture a full network traffic dump for forensic analysis. This is a CBN-reportable event if customer financial data is involved.

6. Modified .env files or config changes you did not make

Your .env file contains database connection strings, API keys, payment gateway secrets, and encryption keys. If this file has been modified and nobody on the team made the change, an attacker may have altered your configuration to redirect payment callbacks to their own endpoint, swap encryption keys to decrypt future traffic, or inject a secondary database connection string for data mirroring.

What to check: Compare the current .env or configuration files against your last known-good version in your secrets manager or version control. Check file modification timestamps. Review your secrets management to ensure credentials are not stored in plaintext on disk. Diff your current production configuration against your infrastructure-as-code templates.

What it means: The attacker has write access to your server's filesystem and is manipulating your application's behaviour at the configuration level. This is particularly dangerous because config changes can redirect payment flows without modifying a single line of application code.

Immediate action: Restore the .env file from your secrets manager. Rotate every credential that was present in the modified file. Audit your deployment pipeline for unauthorized access. Implement file integrity monitoring (FIM) to alert on any future changes to critical configuration files.

7. Missing or truncated access and audit logs

Sophisticated attackers do not just break in - they cover their tracks. If your application logs, access logs, or audit trails have unexplained gaps, truncated entries, or have been deleted entirely for specific time periods, that is a deliberate act of evidence destruction.

What to check: Verify that your log files have continuous timestamps with no gaps. Check log file sizes - a sudden drop in file size suggests truncation. Review log rotation configurations to ensure they have not been tampered with. Verify that your centralized logging pipeline (if you have one) matches what is on disk. Compare local logs against cloud-stored copies.

What it means: An attacker is actively attempting to hide their activities. This is a strong indicator that they have performed high-impact actions (data exfiltration, account creation, privilege escalation) and are covering their trail.

Immediate action: Implement immutable, append-only log storage that ships logs to an external system the attacker cannot access - a separate AWS account, a dedicated SIEM, or even a hardened syslog server. This is not optional for fintechs operating under CBN's Risk-Based Cybersecurity Framework, which explicitly requires tamper-proof audit trails.

8. Cryptocurrency mining processes consuming CPU

Cryptojacking - where attackers install cryptocurrency mining software on compromised servers - is one of the most common post-exploitation activities because it generates direct revenue for the attacker with minimal effort. Your cloud bill goes up, your application slows down, and your customers experience degraded performance.

What to check: Run top or htop and look for processes consuming abnormally high CPU (often 80-100%) with names you do not recognize. Common miner process names include xmrig, minerd, kworker (mimicking a kernel thread), or randomly generated strings. Check for recently created files in /tmp, /var/tmp, or /dev/shm - miners are frequently staged in these temporary directories. Review your crontab for entries that download and execute remote scripts.

What it means: Your server is fully compromised. Cryptojacking is almost always a secondary payload - the attacker had to exploit a vulnerability to install the miner, which means they also had access to everything else on that server, including your database credentials, API keys, and customer data.

Immediate action: Kill the mining process and remove the binary. But critically, do not stop there. The miner is a symptom, not the disease. You must identify and patch the original entry point, rotate all credentials on the affected server, and conduct a full penetration test to find other footholds the attacker may have established.

9. Customer complaints about unauthorized transactions

When your customer support team starts receiving reports of transactions the customers did not initiate, you are no longer looking at a potential compromise - you are in active incident response mode. In the Nigerian fintech ecosystem, where NIBSS data shows electronic fraud losses exceeded ₦18 billion in recent years, these complaints often surface weeks after the initial breach.

What to check: Aggregate all customer complaints related to unauthorized activity. Look for patterns: are the affected accounts clustered by registration date, geographic region, or transaction type? Cross-reference with your authentication logs - were these accounts accessed from unusual IP addresses or devices? Check whether the unauthorized transactions bypass your normal approval workflows, which would indicate business logic manipulation.

What it means: Attackers have either compromised individual customer accounts (via credential stuffing or SIM swap attacks) or have gained system-level access that allows them to initiate transactions directly through your backend.

Immediate action: Freeze affected accounts. Implement velocity checks and transaction amount limits while you investigate. Notify the CBN and NDPC if personal data exposure is confirmed - you have a 72-hour window under the NDPA. Engage forensic investigators to determine whether this is isolated account compromise or systemic backend access.

10. Unexpected cloud billing spikes

Your AWS, GCP, or Azure bill suddenly jumps 300% with no corresponding increase in legitimate traffic or deployment activity. This is not a pricing change - it is an attacker consuming your compute resources, likely for cryptocurrency mining, launching attacks against other targets from your infrastructure, or spinning up additional instances for data processing and exfiltration.

What to check: Review your cloud provider's billing dashboard for unusual resource consumption. In AWS, check for EC2 instances, Lambda invocations, or S3 data transfer volumes you do not recognize. Look for resources in regions you do not operate in - attackers frequently spin up instances in regions like ap-southeast-1 or eu-west-3 that your team never uses. Check IAM access key usage for service accounts that should be dormant. Review your cloud security configuration for gaps.

What it means: Your cloud credentials have been compromised. The attacker has access to your cloud provider account, potentially including your production databases, secrets manager, and deployment pipeline.

Immediate action: Set up billing alerts with aggressive thresholds (50% above baseline). Terminate any unrecognized resources immediately. Rotate all IAM access keys and implement mandatory MFA on your cloud console. Enable AWS GuardDuty, GCP Security Command Center, or Azure Defender for continuous threat detection.

11. Modified cron jobs or scheduled tasks you did not set

Cron jobs are a favourite persistence mechanism for attackers because they execute automatically, survive reboots, and are rarely audited by engineering teams. A malicious cron entry might download and execute a fresh payload every hour, re-establish a reverse shell connection, or periodically exfiltrate new database records to an external server.

What to check: List all cron jobs for every user on the system: check the output of crontab -l for each user, review /etc/crontab, and inspect every file in /etc/cron.d/, /etc/cron.daily/, /etc/cron.hourly/, and /etc/cron.weekly/. Look for entries that use curl, wget, or bash to download and execute remote scripts. Check systemd timers as well - attackers increasingly use systemd timer units instead of cron to avoid detection.

What it means: The attacker has established automated persistence. Even if you clean the initial malware, the cron job will re-download and re-install it on schedule.

Immediate action: Remove any unrecognized cron entries. Kill any processes spawned by those entries. Audit systemd timers. Implement a cron monitoring solution that alerts on any new or modified scheduled task. Include cron job auditing in your regular security review cycle.

12. DNS records pointing to unknown IP addresses

If your domain's DNS records have been modified to point to IP addresses you do not control, the attacker can intercept all traffic to your application - including customer login credentials, payment data, and API requests. This is a DNS hijacking attack, and it is particularly devastating because it can be invisible to your server-side monitoring (your servers are fine; the traffic just never reaches them).

What to check: Run DNS lookups against your domain and all subdomains. Compare the returned IP addresses against your known infrastructure. Check your domain registrar's audit log for unauthorized changes. Verify your DNS provider's access controls - who has permission to modify records? Check for recently added subdomains you did not create, which could be used for phishing campaigns impersonating your brand.

What it means: The attacker has compromised your DNS management account or your domain registrar account. This gives them the ability to redirect your entire customer base to a phishing page that looks identical to your real application.

Immediate action: Correct the DNS records immediately. Enable registrar lock on your domain. Implement DNSSEC if your registrar supports it. Enable MFA on your domain registrar and DNS provider accounts. Set up external DNS monitoring that alerts you within minutes if any record changes.

What Nigerian regulation requires you to do next

Under the Nigeria Data Protection Act (NDPA) 2023, organisations that experience a data breach must notify the Nigeria Data Protection Commission (NDPC) within 72 hours of becoming aware of the incident. The CBN's Risk-Based Cybersecurity Framework further requires licensed financial institutions to maintain tamper-proof audit trails, conduct annual penetration testing, and report cybersecurity incidents to the CBN within 24 hours. Non-compliance penalties under the NDPA reach up to ₦10 million or 2% of annual gross revenue, whichever is greater.

Delaying your response to save face or avoid regulatory scrutiny makes the eventual penalty significantly worse. Nigerian regulators are increasingly treating cover-ups more harshly than the original breach. The best position to be in is one where you detected the compromise through proactive monitoring, responded according to a documented incident response plan, and can demonstrate to regulators that you had reasonable security controls in place.

Related reading

Blog: How hackers steal money from Nigerian fintechs · Top vulnerabilities in Nigerian companies · Cost of a data breach for Nigerian fintechs · .env file security in production

Guides: What to do after a breach · Breach risk assessment for Nigerian fintechs · Fintech security checklist

Services: Penetration testing · Vulnerability assessment · Secure architecture review