Skip to main content

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

SheMo Noransom舍末无勒

Scenario solution

ERP System Encrypted by Ransomware

  • 用友 U8 / NC / 畅捷通 T+
  • 金蝶 K/3 / KIS / 云星空
  • SAP ERP
  • 鼎捷 ERP
  • 浪潮 ERP
  • Microsoft SQL Server
  • Oracle Database
  • IIS / Tomcat 应用服务器

An encrypted ERP is not a single broken database: the application tier, database, attachments and interfaces fail together, halting finance, procurement, production and inventory. This page covers the vulnerability entry points seen in Chinese ERP deployments, the order in which the four tiers are recovered, and how account sets are reconciled at sign-off.

Typical symptoms

  • ERP clients cannot log in, reporting database connection failures, missing account sets, or an empty account-set list
  • On the application server, the program directory, attachment directory, report templates and the database data directory all carry appended extensions
  • The web ERP returns HTTP 500 or displays a ransom page, with ransom notes in the IIS / Tomcat site directories
  • Voucher attachments, scanned contracts, drawings and goods-movement documents will not open, showing blank icons
  • Interface jobs to MES, WMS, e-commerce platforms, tax filing and bank connectivity all fail, with landing files encrypted
  • Unknown aspx / jsp files exist on the ERP server, and web logs show suspicious upload and command-execution requests

Business risk & common mistakes

ERP is the operational core of a business. When it is encrypted the loss is not only data but the processes themselves: no invoicing, no shipping, no goods movement, no reconciliation — and each additional day of downtime compounds the cost.

Understanding the entry point matters. The exposure profile of Chinese ERP deployments is distinctive: applications are often published to both the intranet and the internet, run on Windows servers, share a host with the database, and lag behind on version upgrades. Public reporting documents the TellYouThePass family delivering ransomware at scale through severe flaws in domestic finance software — Chanjet T+ has been mass-exploited in two separate waves: in August 2022 China's national vulnerability sharing platform recorded an arbitrary file upload flaw (CNVD-2022-60632) and reported that users had already been hit with ransomware through it, with Antiy attributing the campaign to TellYouThePass; in June 2023 360 observed TellYouThePass exploiting a T+ command-execution flaw disclosed on 8 June, attacking more than a thousand servers running the system between 9 and 12 June. Historical high-severity flaws such as the Yonyou NC BeanShell remote code execution issue (CNVD-2021-30167) have likewise been scanned and exploited for years. The other common entry sits on the database side: internet-exposed MS-SQL instances brute-forced by the Mallox / Weaxor lineage.

ERP incidents must be inventoried across four tiers; missing any one leads to "the database is restored but the system still will not run":

TierContentsRecovery difficulty
ApplicationERP program directory, patches, registration and licences, custom developmentLicences and customisations are often unbacked
DataAccount-set databases (.mdf / .dbf), logs, backupsSee the database scenarios
AttachmentsVoucher images, scanned contracts, drawings, report templatesOften on a file server or local directory, and easily overlooked
InterfacesConnections and landing files for MES / WMS / e-commerce / tax / bankingRequire reconnection and re-runs, with sequencing dependencies

Common mistakes: reinstalling the ERP into the original directory, restoring an encrypted account-set backup over production, repeatedly starting the database service, deleting encrypted files to free space, and going live before eradication, leading to re-encryption. We do not recommend paying, and we do not negotiate on your behalf.

Our response plan

  1. Isolate, preserve, and inventory all four tiers

    Isolate the ERP application and database servers without rebooting or reinstalling, and image all relevant volumes read-only. The inventory must span all four tiers: program directories and licence information, account-set databases and backups, attachment and report template directories, and interface configuration plus landing files. Preserve web access logs, IIS / Tomcat logs, Windows security logs, database error logs and site-directory file timestamps — the entry point in ERP incidents is frequently on the web tier, and those logs are the key to attribution.

  2. Identify the family and locate the exploited flaw

    Identify the family from extensions and ransom notes, then check two entry classes specifically: application exploitation — tracing suspicious upload and command-execution requests backwards through web logs, diffing new files in site directories, and mapping ERP and middleware versions against known severe vulnerabilities — and database brute force — checking whether 1433 / 3389 were exposed, reviewing failed-logon records, and looking for anomalous command execution in database logs. The conclusion drives hardening and reveals whether other servers on the segment are already affected.

  3. Assess recoverability and design the recovery order

    Assess the three database paths — backup plus log restore, page-level repair, rebuild — alongside recovery sources for attachments and the application tier. Sequence the recovery by business logic: first stand up a working application environment (clean server, matching ERP version, licences), then restore account-set data, then reattach attachments, and finally restore interfaces. This order lets the business see and start checking the system early, rather than discovering a version mismatch only after all the data is in place.

  4. Execute recovery and reconcile with finance

    After recovery in the isolated environment, sign-off must involve finance and the operating departments, and must be measured in business terms rather than "the database restored successfully": does the general ledger balance against subledgers, are closing balances correct by account, do inventory quantities and values match, are receivables and payables complete, are the latest voucher and document numbers continuous, do attachments open, and which interface data needs re-running. Every gap is itemised, stating what must be re-entered manually and what can be pulled again from upstream or downstream systems.

  5. Patch, restructure, and go live

    Patch the specific flaw identified by forensics and upgrade the ERP and its middleware. The ERP should not be published directly to the internet; where external access is required, front it with a VPN or application gateway and restrict sources. Separate the database from the application tier, stop forwarding 1433, and apply least privilege to accounts. Remove web shells and persistence, and reset every credential. Rebuild backups: full account-set backups plus log backups plus attachment directory backups, with one offline or immutable copy, validated by a real restore drill. Finish with an incident report and remediation checklist, and keep heightened monitoring in place after go-live.

Recovery paths

ERP recovery is a composite exercise: each of the four tiers has its own recovery sources and must be assessed separately.

Data tier (account-set databases). The core, following the same paths as the database scenarios: backup plus transaction log restore (the best outcome), page-level repair and table extraction (large account sets often leave considerable room, since many families encrypt only the header of large files), and rebuild where neither suffices. SQL Server-backed systems such as Yonyou U8, Kingdee K/3, Guanjiapo and Suda fall frequently into the second category; Oracle-backed large ERP requires additional attention to archived logs and control files.

Application tier. Easy to overlook and a frequent bottleneck. Confirm whether installation media and version patches can be obtained again, whether licences, dongles and registration information still exist (many companies keep no record), and whether custom development and configuration — bespoke reports, document templates, approval workflows, interface scripts — have source code or backups. The best practice here is a clean reinstall on a new server rather than repairing the encrypted original.

Attachment tier. Voucher images, scanned contracts, drawings and report templates usually live separately, in an application server directory or on a file server. Recovery sources include backups, snapshots, carved deleted files, and copies held locally by the departments themselves — finance often archives scanned vouchers locally, and procurement and sales usually hold electronic contracts.

Interface tier. Data channels to MES, WMS, e-commerce platforms, tax filing and bank connectivity must be reconfigured and re-run. The good news is that this tier's data usually exists in full on the counterpart system, and can be pulled back to fill gaps — an underrated resource in ERP recovery.

Stated plainly: the recovered account set will likely have a time gap requiring manual re-entry, and customisations without source code may need reimplementation. We avoid "100%" and "guaranteed recovery"; the assessment sets expectations and gaps per tier. No ransom payment, no negotiation.

Common ransomware families

Hardening recommendations

  • Do not publish the ERP directly to the internet. Where external access is required, front it with a VPN or an authenticated application gateway and restrict source IPs; never port-forward the web tier directly. Public reporting documents severe flaws in domestic finance software being used for large-scale ransomware delivery.
  • Keep the ERP and its middleware patched. Maintain a version register and follow vendor security bulletins and CNVD / CNNVD advisories. Yonyou, Kingdee, Digiwin and the middleware and web components they depend on all belong in scope — do not defer upgrades indefinitely out of fear of disruption.
  • Separate the application and database tiers. Do not install the ERP application and SQL Server on the same machine; keep database ports internal, apply least privilege to accounts, and eliminate weak sa passwords and xp_cmdshell.
  • Forbid execution in upload directories. Disable script handling for attachment and upload paths in IIS / Tomcat, and scan site directories regularly for newly added executables (web shell detection).
  • Back up all four tiers, not just the database. Full account-set and log backups, attachment directories, application configuration and customisation source code, plus licences and registration details — with at least one offline or immutable copy.
  • Keep a rebuild package. Store ERP installation media, version patches, licence and dongle information, customisation source code and deployment documentation offline; it saves enormous time during recovery.
  • Drill restores. Every six months, fully restore one account set in an isolated environment and have finance operate it, proving both the backup chain and the application environment work.
  • Cover ERP and database servers with EDR, monitoring precursor behaviour such as unexpected writes into site directories, database services being stopped, and shadow-copy deletion.

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.

Related questions

Related industries

FAQ

Frequently asked questions

  • Our Yonyou / Kingdee account set is encrypted — what does recovery look like?

    In four steps. First, inventory all four tiers: application and licences, account-set database, attachment directories, interface configuration. Second, assess database recoverability — restore where a usable full backup and logs exist; where no backup survives, examine the .mdf's encryption coverage, since large account sets are often header-only encrypted and amenable to page-level repair and table extraction. Third, reinstall the matching ERP version on a clean server, attach the recovered account set and restore the attachments. Fourth, have finance reconcile for sign-off — ledger against subledgers, closing balances, document continuity — itemising the gaps before deciding how to re-enter.

  • Did the attackers come in through an ERP vulnerability?

    It is one of the common entry points, but it must be confirmed from logs rather than assumed. Public reporting documents the TellYouThePass family delivering ransomware at scale through severe flaws in domestic finance software, with analysis describing attackers writing a backdoor into the web service directory via an arbitrary file upload flaw and then executing remote code on request; historical issues such as the Yonyou NC BeanShell remote code execution flaw have likewise been scanned and exploited for years. The other frequent entries are database brute force and weak-password RDP. We draw a specific conclusion and timeline from web access logs, site-directory file changes and security logs.

  • The database is restored but the ERP still will not open — why?

    Because an ERP is more than its database. Typical blockers: the program directory was encrypted and needs reinstalling; licence or dongle information is lost, preventing registration; versions do not match — the restored account set belongs to an older build than the fresh install, or vice versa; customisations are missing (bespoke reports, document templates, approval workflows, interface scripts); or attachment directories were not restored, so voucher images will not open. This is why we insist the four-tier inventory happens during assessment, rather than discovering missing pieces halfway through.

  • Do interface feeds (MES, e-commerce, tax) also have to be restored?

    Yes, though this tier usually offers the most room: the counterpart systems generally hold complete copies. The approach is to rebuild interface configuration and connections, then pull back from the counterpart across the relevant time range and re-run: marketplace orders and refunds, tax filings and invoices, bank transaction records, MES / WMS work orders and goods movements. Watch sequencing and idempotency so nothing is posted twice. These re-runs are normally scoped with the business to an agreed cut-off point and validated during reconciliation.

  • Could the recovered data have missing or wrong entries? How do we confirm?

    Gaps are possible, which is why reconciliation is mandatory. Our sign-off checklist typically covers: whether the general ledger balances against each subledger; whether closing balances and brought-forward figures agree by account; whether inventory quantities and values match a physical count; whether receivables and payables detail is complete; whether voucher and document numbers are continuous without jumps; whether attachments open; and whether interface data has been re-run. Each discrepancy is recorded with its cause — a gap after the backup point, rows lost during repair, or an interface not yet re-run — and finance decides how to re-enter or adjust.

Updated