Skip to content
Book a demo
All posts
News

Columbia, South Carolina responds to cyberattack that shut down city systems

The city of Columbia, South Carolina says it is responding to a cyberattack that has shut down several government systems, including the platform residents use to pay utility bills. The state's law enforcement division is leading the investigation.

Published
Reading
3 min
By
Kairo

The city of Columbia, South Carolina said it is responding to a cyberattack that has shut down several government systems. Columbia is the capital city of South Carolina and has about 150,000 residents. A city spokesperson told Recorded Future News that the IT department recently identified suspicious activity and contacted the state's South Carolina Law Enforcement Division (SLED), which is now leading the investigation.

What happened

The systems impacted by the attack include the MyColaSC platform that citizens use to pay utility bills, report non-emergency issues and access other city services. The attack also knocked out Geographic Information Systems and systems underpinning animal services.

The city did not respond to questions about whether it is dealing with a ransomware attack. No hacking group has taken credit for the incident as of Wednesday, and no group has been named as responsible.

A spokesperson told Recorded Future News that the city's IT department recently identified suspicious activity and contacted the state's South Carolina Law Enforcement Division (SLED), which is now leading the investigation.
The Record

How it was done

The published details do not describe an initial access method, a vulnerability or a malware family. What is known is the sequence: the IT department identified suspicious activity, the state law enforcement division was contacted, and several systems were taken out of service.

The affected services span different functions, from citizen payments to mapping to animal services. That pattern is worth noting for anyone running shared municipal infrastructure, but the cause has not been stated publicly.

What to check

If you run resident-facing services on shared internal infrastructure, these checks are a reasonable place to start.

  1. Map which services share an identity provider

    List every public-facing portal and the directory or single sign-on tenant it authenticates against. In Entra ID or Okta, export the application inventory and group it by tenant. If one compromised directory would take down billing, mapping and back office apps at once, that is a concentration risk.

  2. Test that portals can fail independently

    Pick one payment or request portal and simulate the loss of its database or API dependency in a staging environment. Confirm other services stay up and that the portal shows a maintenance page rather than a stack trace. A cascading failure across unrelated services means the segmentation is not real.

  3. Verify admin access paths into GIS and operations systems

    Check whether GIS servers, asset databases and departmental applications are reachable from general staff subnets. Run a scan from a workstation VLAN against the ports those systems use and see what answers. Anything administrative that responds without a jump host or multi-factor prompt needs to be closed.

  4. Confirm restores actually work for each service tier

    Pull the most recent backup of one citizen-facing database and restore it to an isolated host. Time the restore and validate record counts against production. If you cannot complete the restore or the backup is on a share writable by the same service accounts, fix that before anything else.

  5. Review detection coverage for lateral movement

    Query your SIEM for new service account logons, unusual remote execution and account creation across servers in the last thirty days. Confirm domain controllers and application servers are forwarding logs and that alerts route to someone on call. Silent gaps in forwarding are a common finding.

  6. Rehearse the handoff to outside investigators

    Write down who calls law enforcement, who preserves disk and memory images, and where those images are stored. Walk the plan through once with the IT and legal teams. If the first step would be to reimage affected hosts, the evidence is gone before anyone can use it.

Keep reading

More from the team
that verifies every change.

All posts

See what your application allows before an attacker does.