When a Security Incident Tests a Software Partnership: How BHSoft Supported a U.S. Client Through a Major AWS Compromise

In software engineering, a long-term partnership is built over time.

It starts with delivering on requirements, solving technical problems, and earning trust through consistent execution. As that trust grows, so does the scope of collaboration.

For BHSoft, one of our U.S.-based clients has been a valued partner for over a year. Over that time, the BHSoft team has gradually expanded alongside the client's growing product and engineering needs, becoming increasingly involved in its technology environment.

Then, in late July 2026, that partnership faced one of its most serious tests.

An external attacker compromised a production workload in the client's AWS​ environment, gained highly privileged AWS access, and generated approximately USD 8**,***.** in unauthorized Amazon Bedrock usage within just three days.

The incident was not caused by a new configuration introduced by BHSoft. Our investigation found that the vulnerabilities involved in the initial compromise were part of legacy infrastructure and security configurations inherited from the client's previous DevOps setup, predating BHSoft's current management of the environment.

Once the incident was identified, BHSoft immediately worked alongside the client to investigate, contain the compromise, preserve evidence, restore production operations, and strengthen the environment against similar risks.

This became a powerful reminder that the value of a long-term engineering partnership is not only measured by what happens when everything goes according to plan, but also by how a team responds when an unexpected crisis occurs.

Understanding the Legacy Risk

The incident began with a production GeoServer workload running on Amazon EC2.

The investigation identified several legacy security and infrastructure configuration gaps that had been inherited from the previous DevOps setup.

First, the GeoServer instance was running an outdated version with a security vulnerability.

Second, the service was exposed to the public Internet through port 8080.

Third, the EC2 instance was associated with an overly privileged instance profile capable of performing administrative actions within the AWS environment.

These configurations were pre-existing conditions inherited by the current BHSoft team, rather than changes introduced as part of BHSoft's management of the environment.

The combination created a serious attack path:

Internet-exposed service → vulnerable GeoServer → compromised EC2 → compromised AWS credentials → administrative access → unauthorized cloud resource usage.

This sequence demonstrates an important security principle: a vulnerability on one workload can have consequences far beyond that workload when identity and access controls are not sufficiently restricted.

It also highlights why inherited cloud environments require a thorough security and configuration review when responsibility for their management changes hands.

From EC2 Compromise to AWS Account Abuse

Between July 26 and July 29, 2026, an external attacker compromised the production GeoServer workload hosted on Amazon EC2.

The attacker obtained temporary AWS credentials assigned to the EC2 instance role and subsequently used those credentials externally from a public IP address.

Using the compromised credentials, the attacker created an unauthorized IAM administrator account, generated two long-lived access keys, queried Amazon Bedrock service quotas, and established a 36-hour federated administrator session.

At that point, the incident had moved beyond a compromised server.

The attacker had obtained powerful access to the broader AWS environment.

The subsequent activity showed clear signs of automated abuse. The attacker used Amazon Bedrock across multiple AWS regions, including North America, Europe, and Asia, and overwhelmingly targeted premium Claude models.

Approximately 96% of the unauthorized charges were associated with the Claude Opus model family, with Claude Opus 5 alone accounting for approximately 77% of the total unauthorized cost.

The scale was extraordinary.

Approximately USD 8**,***.** in unauthorized Bedrock usage was generated over roughly three days — equivalent to approximately:

• USD 2**,*** per day
• USD 1*,*** per hour
• USD 1** per minute

The activity was fundamentally inconsistent with the client's normal enterprise operations. It involved multiple model families, multiple AWS regions, sustained automated consumption, and extensive prompt-cache activity.

What began as a compromised production workload had therefore become a major cloud security and financial incident.

Responding Under Pressure

When an incident reaches this scale, technical expertise alone is not enough.

The response requires speed, coordination, communication, and a clear understanding of the affected environment.

BHSoft immediately worked closely with the client to investigate and contain the incident.

The team worked intensively throughout the incident, including over the weekend, focusing on both immediate containment and evidence preservation.

Rather than simply shutting down affected resources, the investigation preserved evidence from multiple sources, including:

• AWS CloudTrail logs
• Application Load Balancer logs
• GeoServer application and server logs
• VPC Flow Logs
• AWS Cost Explorer data
• IAM records
• EC2 configuration records
• Source IP information
• Access-key identifiers
• Relevant timestamps and AWS event IDs

Preserving this information was critical for reconstructing the attack path, understanding the scope of the compromise, and supporting the subsequent investigation by AWS Security.

At the same time, the unauthorized IAM user and associated credentials were removed or disabled, and the affected EC2 instance was terminated.

BHSoft and the client also coordinated with the relevant security teams. AWS Security initiated an investigation, while Anthropic Security was notified and asked to preserve relevant telemetry associated with the unauthorized Bedrock activity.

The objective throughout the response was not simply to stop the immediate threat, but to establish enough evidence and understanding to determine what had happened and prevent the same weaknesses from becoming an entry point again.

Restoring Production Under Incident Conditions

Containing the security threat was only part of the challenge.

Because the affected AWS account was under review following the compromise, the production environment could not simply return to normal immediately. At the same time, the production database remained accessible.

This gave the engineering team a path toward restoring application services while the AWS security review was underway.

BHSoft deployed the API stack through a separate AWS account and connected the newly deployed services to the existing production database.

This required the team to work carefully under incident conditions while maintaining the integrity and continuity of the production data and application environment.

Once the new API deployment was ready, production access was restored after the AWS team completed its security review of the compromised account.

The production environment has since returned to normal operation.

The approximately USD 8**,***.** in unauthorized Amazon Bedrock charges, however, remain a separate matter. At the time of writing, AWS's billing team is continuing to review the charges associated with the incident.

This distinction is important: technical recovery was achieved, while the financial review remains ongoing.

Strengthening Monitoring After the Incident

Incident response does not end when the immediate threat is contained.

Following the incident, BHSoft and the client reviewed the environment's monitoring and detection capabilities and strengthened visibility into both security activity and cloud consumption.

Several monitoring measures were reviewed or strengthened.

1. AWS CloudTrail

CloudTrail was already enabled in the environment and provided an important source of evidence during the investigation.

Its audit trail helped the team understand AWS API activity, identify unauthorized actions, and reconstruct important parts of the attack timeline.

2. AWS Budgets

Budget notifications were updated to provide earlier visibility into unexpected spending activity.

The objective was to make abnormal spending visible as early as possible, providing an additional signal when cloud consumption deviates significantly from expected patterns.

3. AWS Cost Anomaly Detection

Cost Anomaly Detection was configured to monitor AWS services for unusual spending patterns.

For an environment using cloud services at scale, cost monitoring is not merely a financial control. In the context of this incident, it also became part of the security detection strategy.

An unexpected surge in cloud consumption can be a signal of compromised credentials, unauthorized workloads, cryptomining, or large-scale AI service abuse.

4. Amazon GuardDuty

Amazon GuardDuty was already present as part of the environment's security controls, providing an additional layer of threat detection.

The incident reinforced the importance of combining these services with sound identity management, vulnerability management, network controls, and continuous monitoring.

What This Incident Taught Us

The incident did not result from a single failure.

It demonstrated how legacy infrastructure, outdated software, excessive permissions, and public network exposure can combine to create significant risk when they remain undetected.

It also reinforced why inherited environments require careful assessment.

When a new engineering team takes responsibility for an existing production environment, understanding what is already there is just as important as building what comes next. Legacy configurations can remain invisible until a security incident exposes their consequences.

For organizations operating in the cloud, several principles remain fundamental:

• Secure workloads.
• Least-privilege access.
• Controlled network exposure.
• Credential protection.
• Continuous logging.
• Threat detection.
• Cost monitoring.
• And a prepared incident response process.

No single security service can replace these foundational practices.

When a Partnership Is Put to the Test

The technical lessons from the incident are important. But there is another lesson that is equally significant.

A software partnership is tested most when things do not go according to plan.

Over nearly two years of working together, BHSoft and the client had developed an understanding of the systems, workflows, and technical environment involved.

When the incident occurred, that existing relationship allowed both teams to work together immediately and continuously.

BHSoft did not simply receive a ticket and wait for normal working hours. The team worked closely with the client throughout the incident, including over the weekend, to investigate the compromise, contain the threat, preserve evidence, coordinate with AWS and other security teams, and restore production services.

That is an important part of what a long-term engineering partnership means.

The value of an engineering partner is not only in building new features or maintaining existing systems.

It is also in being there when an unexpected problem requires immediate action.

Beyond Incident Resolution

Security incidents are often measured by their immediate consequences: downtime, compromised credentials, unexpected costs, or lost productivity.

But the longer-term value of an effective response is measured differently.

It is measured by what an organization learns and what changes afterward.

For the client, the incident highlighted areas where security controls, cloud permissions, infrastructure configuration, and monitoring could be strengthened.

For BHSoft, it reinforced the responsibility that comes with being a long-term engineering partner.

The incident originated from legacy configurations inherited from the previous environment setup. But once the issue emerged, BHSoft's responsibility was clear: help the client respond quickly, work through the technical complexity, and support the recovery process until the production environment was back to normal.

The experience was difficult, but it demonstrated the value of a partnership built over nearly two years of trust.

Technology can fail. Security incidents can happen. What matters is how prepared you are to respond — and who stands with you when they do.

Conclusion

At BHSoft, we understand that supporting a technology environment goes beyond software development. It also means being ready to respond when unexpected security and infrastructure challenges arise.

Our approach combines engineering expertise, cloud infrastructure knowledge, security awareness, and close collaboration with our clients to help build resilient systems and respond effectively when incidents occur.

Whether you are managing a legacy cloud environment, strengthening your security posture, or looking for a reliable engineering partner to support your production systems, BHSoft is ready to work alongside your team.

Looking for a trusted software engineering partner? Contact BHSoft today to discuss your project!