Skip to main content

Hit by ransomware? Isolate affected systems now. Do not reboot or reformat.

SheMo Noransom舍末无勒

Scenario solution

OA Collaboration System Encrypted by Ransomware

  • 泛微 e-cology / e-office
  • 致远 OA（Seeyon）
  • 蓝凌 OA
  • 通达 OA
  • Apache Tomcat / WebLogic
  • Microsoft SQL Server
  • Oracle Database
  • 附件与全文检索索引库

An encrypted OA system halts document circulation, approvals, contract archives, HR and knowledge bases at once — and because OA is so often published to the internet, it is frequently the attacker's first foothold. This page covers its vulnerability profile, the twin-track recovery of attachments and database, and how to check for lateral spread.

Typical symptoms

  • The OA portal will not load, returning HTTP 500 or a ransom page, with Tomcat / WebLogic services failing
  • The OA application directory, attachment store and database data files all carry appended extensions
  • Active workflows and task lists have disappeared; after login the page is blank or reports a datasource error
  • Archived documents, scanned contracts, HR records and meeting minutes cannot be downloaded or opened
  • Unknown jsp / class files appear in the site directory, with suspicious upload and command-execution requests in the web logs
  • Other servers on the same segment — file servers, ERP, databases — begin failing in turn, indicating lateral movement

Business risk & common mistakes

OA carries a risk profile distinct from ERP: it is almost always published to the internet. To let staff approve documents while travelling or at home, the OA portal is typically exposed directly, making it one of the most exposed business systems in the estate — and a favourite pivot into the internal network.

Public sources show that the major OA products have all had severe vulnerabilities widely exploited. Weaver e-cology was the subject of a CNCERT advisory for an unauthenticated SQL injection flaw allowing attackers to retrieve sensitive database information without credentials; its BeanShell component also permitted unauthenticated access leading to remote command execution, alongside page-based file upload and database configuration disclosure issues. Seeyon OA has likewise been publicly documented with session leakage, multiple SQL injection points, unauthorised access, arbitrary password modification and XXE issues in bundled components. What these share is that they are exploitable without logging in, which is why scanners probe for them continuously.

Layers of risk:

  • Business interruption. Documents, approvals, seal usage, contract archiving and expense workflows all stop, affecting every employee and drawing immediate management attention.
  • A launch point for lateral movement. OA servers usually have broad reachability internally and are often domain-integrated. Having taken the OA server, attackers commonly pivot to file servers, ERP, databases and domain controllers — an OA incident must be handled together with an internal lateral-movement sweep.
  • High data sensitivity. HR records, payroll, contracts, tender documents and meeting minutes all live in OA. If exfiltrated, personal information and trade secrets are involved, so notification obligations must be assessed in parallel.

Common mistakes: reinstalling OA over the original directory, deleting the encrypted attachment store to free space, restoring the database while ignoring attachments, and rushing back online before a lateral sweep. We do not recommend paying, and we do not negotiate on your behalf.

Our response plan

  1. Isolate, preserve, and start a lateral sweep at once

    Cut the OA server's external and internal access without rebooting or reinstalling, and image the relevant volumes read-only. Start an internal lateral sweep at the same time: OA is frequently the attacker's first stop, so assume other servers may already have been reached. Evidence priorities include web access logs across the full period, site-directory file timestamps and new files, Tomcat / WebLogic logs, database logs, Windows security logs, scheduled tasks and services, and changes to local and domain accounts.

  2. Locate the exploited flaw and identify the family

    Work backwards through the web logs: unauthenticated access paths, requests bearing SQL injection signatures, file uploads and dropped jsp files, command-execution parameters, anomalous user agents and request sequencing. Cross-check the OA product and middleware versions against publicly documented severe vulnerabilities, and identify the family from extensions and ransom notes. The root-cause conclusion is not only for hardening — it scopes the lateral sweep, because what credentials the attacker took from OA usually determines where else they could go.

  3. Twin-track assessment: database and attachments separately

    OA data splits into two parts with entirely different recovery paths. The database holds workflows, forms, permissions and metadata, and follows the database routes: backup plus logs, page-level repair, or rebuild. The attachment store is a directory mixing huge numbers of small files with large ones — document bodies, scans, images, video, full-text search indexes — and must be assessed by file type: large files are often only partly encrypted and repairable, while small files are usually fully encrypted and depend on backups, snapshots and distributed copies. Both must be recovered together, or workflows open with empty attachments.

  4. Rebuild clean and restore the data

    Do not repair the OA application in the encrypted original environment. Deploy the same OA and middleware versions on a clean server, patch them fully, and then import the recovered database and attachments. Suggested order: restore the database, users, organisational structure and permissions so the system accepts logins; then restore attachments and verify that attachment paths match the database records; finally rebuild the full-text search index. Validate the environment in an isolated segment, and have the business sample historical workflows and attachment readability before go-live.

  5. Reduce exposure, patch, and harden the estate

    Hardening OA centres on reducing internet exposure: move to VPN or zero-trust gateway access where possible, and where public publication is unavoidable, front it with a WAF, restrict admin console paths, and disable unnecessary interfaces and test pages. In parallel, upgrade the OA and middleware, patch the specific flaw forensics identified, remove web shells and persistence, and reset all OA and domain credentials. Because OA is so often a pivot, hardening cannot stop at one host — it must cover every affected system found by the sweep — and backups must be rebuilt to include the database, attachments and configuration, with an offline or immutable copy.

Recovery paths

The key insight for OA recovery: workflow data and attachments must be recovered as a pair. Restoring only one half is effectively restoring nothing.

The database. Holds workflow instances, form data, organisational structure, permissions and the attachment index. Recovery follows the database routes: backup plus log replay (best), page-level repair and table extraction, or rebuild where necessary. OA databases are usually moderate in size, and where the family encrypts only the headers of large files, repair prospects are reasonable.

The attachments. The largest body of work in an OA recovery. Attachment stores are typically organised by year and month across hundreds of thousands or even millions of files. Recovery sources include backups and snapshots, carving the deleted originals, partial-encryption repair on large files, and distributed copies — attachments in staff mailboxes, local download folders, instant-messaging transfer records, printed archives, and the same documents held by counterparties. For official documents and contracts, these copies frequently restore the critical items.

The full-text search index. A damaged index generally does not need recovering — it can be rebuilt once data and attachments are back. This is often overlooked, adding needless work.

Configuration and customisation. Workflow templates, form designs, portal layouts, single sign-on and third-party integration settings are application-tier assets. Without exported backups they may need reconfiguring, so their source must be established before recovery starts.

Stated plainly: the recovery rate for attachments is usually lower than for the database, particularly where small files were fully encrypted and no usable backup exists. The assessment gives separate expectations for database and attachments, and lists what is definitively unrecoverable. We avoid "100%" and "guaranteed recovery"; we do not pay ransoms and we do not negotiate.

Common ransomware families

Hardening recommendations

  • Reconsider whether OA must be published to the internet at all. Prefer VPN or zero-trust gateway access; where public publication is required, front it with a WAF, hide or restrict admin console paths, and disable test and debug interfaces.
  • Keep OA and middleware patched. Public sources document severe, unauthenticated SQL injection, command execution, file upload and configuration disclosure flaws across major OA products including Weaver and Seeyon, scanned for continuously. Maintain a version register and follow vendor bulletins and CNVD / CNNVD advisories.
  • Segment the OA server. Do not let it reach database clusters, domain controllers or core business segments directly; open only necessary ports and restrict egress traffic too.
  • Do not run OA services as a domain administrator. Use least-privilege service accounts and a dedicated database account, so a compromised OA server does not hand over domain credentials.
  • Forbid execution in upload directories and hunt for web shells. Disable script handling on attachment and upload paths, periodically diff the site directory file list, and alert on newly added jsp / aspx files.
  • Back up attachments and configuration, not just the database. Include the attachment store, workflow templates and form designs, and integration configuration, with one offline or immutable copy. Attachment stores are large, so combine incremental backups with periodic full ones.
  • Strengthen authentication. Enable multi-factor or token-based verification for OA logins, disable default and test accounts, remove departed users promptly, and alert on anomalous logons.
  • Cover the OA server with EDR and watch for lateral behaviour — new services, scheduled tasks, unusual internal scanning and SMB connections. OA is a common pivot, and early detection stops the spread.

Emergency response

Data already encrypted? Stop and let an engineer look first

We do not pay ransoms and we do not negotiate with attackers. Engineers run a free assessment first, then propose a recovery plan and a firm quote.

+86 15639272850See contact details

Related industries

FAQ

Frequently asked questions

  • After OA encryption, can documents and contract attachments be recovered?

    Consider the two parts separately. Database content — workflow records, form data, approval comments — has a relatively good chance, especially where a backup exists or the .mdf was only header-encrypted. Attachments are harder: the store is dominated by small files that are usually fully encrypted, so recovery leans on backups, snapshots and carving the deleted originals. The good news is that official documents and contracts usually have distributed copies — in the mailboxes of both parties, local download folders, messaging history, printed archives, and with counterparties — and these frequently restore the critical items in practice.

  • If the OA server was taken, are our other internal systems at risk?

    Assume they were reached and sweep accordingly. OA is typically internet-facing with broad internal reachability, making it a favoured pivot. Handling must include checking the database connection strings and credentials stored on the OA server, the privilege scope of its service accounts, whether it ran under a domain account, recent internal scanning and SMB / RDP connections originating from it, and whether rogue accounts or scheduled tasks have appeared on other servers. Cleaning only the OA host without a lateral sweep is the most common handling error in this scenario.

  • Which OA vulnerability did the attackers use?

    That must be confirmed from logs. Public sources document unauthenticated, severe vulnerabilities across the major OA products: Weaver e-cology has a publicly advised front-end SQL injection flaw, its BeanShell component permitted unauthenticated access leading to remote command execution, and file upload and configuration disclosure issues exist as well; Seeyon OA has documented session leakage, SQL injection, unauthorised access and XXE issues in bundled components. All are discoverable at scale by scanners. We draw a specific conclusion from request signatures in web access logs, the timing of dropped files in the site directory, and middleware logs — rather than vaguely naming a candidate flaw.

  • The full-text search index was encrypted too — does it need separate recovery?

    Usually not. The full-text index is derived from the database and attachments, making it rebuildable content: once those are restored, simply run the index build again. Spending effort recovering the index store is wasteful, and because it typically consists of large numbers of small files, the cost is high and the return low. During assessment we explicitly separate "original data that must be recovered" from "derived data that can be rebuilt", so time is not spent on the latter.

  • OA holds HR and payroll data — should we treat this as a data breach?

    It must be assessed, and the assessment should start early. Current ransomware families routinely exfiltrate before encrypting, and OA holds highly sensitive material: HR records, payroll, contracts and tender documents. During forensics we focus on exfiltration indicators — anomalous egress traffic, staged archives, cloud storage and FTP upload records, and the transfer tools used — to produce a technical conclusion on whether data left and what scope it covered. That conclusion is the factual basis for your legal and compliance teams to assess obligations under the Personal Information Protection Law, the Data Security Law and cybersecurity incident reporting rules. We supply the facts, not the legal judgement.

Updated