Ransomware encrypted Humboldt Institute's ERP and file servers: actions for people and organisations

Colombia’s Alexander von Humboldt Biological Resources Research Institute has disclosed a ransomware attack on its data centre. Attackers encrypted information in its ERP system and connected file servers, then demanded a ransom. Some services remain unavailable while the infrastructure is restored.

The notice also describes a possible impact on information containing personal data, including names, identity-document numbers, mobile numbers and email addresses. It does not establish that every person connected with the institute lost every listed data type. The scope is still being assessed.

What the Humboldt Institute confirmed

The IT team detected the attack on 20 September. Ransomware affected the data centre, including the ERP system and associated file-storage servers. Information in those systems was encrypted, and the attackers demanded payment for its recovery.

After discovery, the institute activated its response procedures, isolated affected equipment and closed associated internal and external connections. It also filed a report with support from the competent authorities. Service restoration remains in progress.

On privacy, the institute refers to a possible impact on information containing personal data. The statement does not confirm that all named categories were stolen or published. It does confirm system encryption and warns people to expect messages that misuse the organisation’s identity.

What someone whose data may have been present should do

Do not trust a message simply because the institute’s name appears in its header or caller ID. A criminal can exploit the public announcement without possessing any stolen data. A genuine name, email address or phone number is also not proof of the sender’s identity.

The institute advises caution when a contact requests passwords, verification codes, personal details, credentials, financial information or payment. If a message claims to concern the incident, navigate independently to the official site or use a published contact channel. Do not reply through an address or number supplied by the suspicious message.

Protect accounts where the email address or phone number is used for recovery. Use unique passwords and strong authentication. Contact data appearing in an incident does not by itself require every password to be changed, unless a password, recovery code or other credential may also have been present in a document.

Over the coming months, watch for messages tailored to a genuine relationship with the institute. An attempt may arrive long after media attention has faded and refer to an invoice, survey, record update or supposed reimbursement.

Why losing ERP is a business problem, not merely an IT problem

ERP often connects finance, procurement, contracts, human resources, projects, inventory and reporting. Its loss can halt payment approvals, document access, reconciliation and decision-making. File servers may hold working copies of agreements, analysis and operational documentation.

A business continuity plan must therefore describe more than how to turn the system back on. It needs fallback rules for approving payments, recording changes, contacting suppliers and reconciling emergency transactions later.

Temporary operations must not remove fundamental controls. Attackers and fraudsters can exploit confusion with false payment orders or supplier bank-account changes. Every exception needs an owner, an expiry and a second approval channel.

A backup must survive the same attack

The statement does not say whether backups were affected or how long restoration will take, so those details should not be inferred. The case nevertheless reinforces that a backup is useful only when it can be restored safely.

An organisation should keep copies separated from ordinary administrator accounts and the live environment. It needs immutable or offline versions, a known recovery point, integrity testing and a rehearsed end-to-end restoration process. A daily copy reachable through a compromised administrator account may be encrypted with production.

Recovery should not blindly restore an entire image. The team must understand the initial path, isolate suspect accounts and tools, rebuild from a trusted source, rotate credentials and monitor for recurring activity.

How an organisation should communicate during ransomware

The first notice does not need every answer, but it should distinguish confirmed facts from continuing investigation. Here, encryption of specified system classes, a ransom demand, isolation steps and possible personal-data impact are confirmed. The scale of any data breach remains unresolved.

Useful communication also tells recipients what to do and how to identify official contact. Support teams need consistent answers and each update should carry a date. An information gap creates room for fake “consultants” impersonating the attacked organisation.

Internally, maintain a decision log: when systems were isolated, which services depend on ERP, who approved fallback operations, which backups were considered trusted and why. The record supports recovery, legal duties and the later root-cause review.

Should the ransom be paid?

The notice confirms a ransom demand but does not disclose the institute’s decision. It should not be guessed. Payment does not guarantee working decryption, deletion of stolen copies or an end to extortion. It may also create legal and sanctions risks depending on the actor and jurisdiction.

The decision needs leadership, legal counsel, incident-response specialists, the insurer and relevant authorities. The most valuable preparation is the ability to continue services and rebuild systems without depending on a criminal’s promise.

Source facts and Breachroad’s conclusions

The Humboldt Institute statement confirms the detection date, encryption of ERP and file servers, ransom demand, isolation, service disruption and possible impact on identity and contact data. It does not name an actor or establish the complete scope.

The personal response, ERP fallback model, backup requirements and communication principles are Breachroad’s conclusions. Organisations can prepare with a 3-2-1 backup strategy and an incident response plan. Decision-making and fallback operations should be rehearsed through an incident-response tabletop exercise.