SparroWocky: which libraries is the approved application loading?

What the researchers observed

In its September 17, 2026 analysis, ESET attributed SparroWocky to FamousSparrow with high confidence and described government targets in Latin America. The analyzed deployment combines a legitimate executable, malicious DLL and payload file through DLL side-loading. This supports questions about loaded components without establishing compromise of every approved application or regional business. The observed loading mechanism does not determine each organization’s initial entry vector.

The unit of trust exceeds the initial file

Choose an application supporting a necessary business function. Identify its approved distribution, version and expected components. A review stopping at the executable name leaves unanswered which libraries participate in execution and who may change them in the examined environment.

Microsoft documentation explains risks when applications search for libraries in directories attackers can control. Use it to ask the supplier how its product finds dependencies. Do not assume a universal search order for every application or treat one setting as complete protection.

Connect distribution, permissions and execution

Compare the approved reference with a company-managed test installation. Record file location, origin, version and relevant permissions. Where differences appear, request an explanation from the product owner before classifying an unfamiliar file as malicious. Legitimate updates also need to appear in the comparison reference.

The change-distribution analysis helps identify who can publish and execute changes. Here, also follow what loads after the program starts. State the observation tools’ limits: a partial module list does not necessarily represent complete execution.

• Reference: distribution and components accepted by operations.
• Permission: identities able to modify relevant files.
• Observation: loaded component, process and recorded time.
• Decision: explained difference, outstanding question or referral.

Observe legitimate work before simulating a deviation

Use a staging installation and a task with fictitious data. Agree beforehand what information may be collected and how long it can be kept. Follow the process, components the tool can observe and destinations needed for the task. Retain correlation identifiers without gathering user documents merely for convenience.

Then use a synthetic event clearly identified as an exercise to check whether a difference reaches its owner. This tests observation and handling without proving that an actual loading attempt would be prevented. Replacing libraries, running malware or contacting campaign infrastructure is unnecessary to test this part of the process.

A difference needs an operational decision

The analyst should connect the event to its application, machine and comparison reference. An ownerless rule can accumulate alerts while operations lacks direction. Define who checks the difference, what additional information is needed and when an indication should enter the incident-response process.

The Defender evidence review helps distinguish observed state from information age. Here, also record component coverage. Old or incomplete observations cannot establish absence of deviation, while an isolated difference establishes neither attribution nor an incident’s initial mechanism.

Execution controls need their own assessment

If the business needs prevention evidence, define a separate authorized test with harmless behavior, a denial criterion and agreed recovery. The team should understand impacts on the application and legitimate dependencies. Simulating an alert and testing a control are different deliverables whose conclusions need to remain separate.

At closure, record the accepted reference, examined sample, resolved differences and exclusions. Reassess following version, distribution or permission changes. Make trust in observed execution verifiable without promising that an approved-program list eliminates every attack path.

October 20, 2026: Siemens Software Center and copies outside inventory

Editorial update: October 20, 2026

This update was prompted by Cyber Security Brazil’s report. On October 19, Siemens confirmed active exploitation of CVE-2026-110936 using a genuine executable and attacker-supplied DLLs. The company stated that it knew of no compromise of its systems, products or update channel. This does not identify the same campaign described by ESET above.

Advisory SSA-580366, published October 15 and updated October 19, lists versions before 4.0.9.8 as affected, with remediation in that version or later. It describes an authenticated local attacker; published vectors indicate high privileges. According to Siemens, existing installations update automatically on their next startup.

For an enterprise review, distinguish the managed installation from unexpected copies found in other directories. An update record for the known installation leaves the question of another executable on the machine open. Compare its path, origin, version and execution context with approved inventory; a difference needs assessment before any conclusion about compromise.

Request two forms of closure evidence: confirmation of the corrected version across the managed set and a decision on each copy whose origin remains unexplained. Where evidence suggests unauthorized activity, preserve available records and refer it to incident response. The benign exercise described in this article remains appropriate for checking escalation and ownership, with its coverage stated.

Frequently asked questions

Related reading

• Authority to distribute a change
• Observed state and evidence freshness
• Component acceptance before execution

Sources and references

• ESET: primary SparroWocky analysis
• Microsoft Learn: dynamic-link library security

Original Pentesty analysis, published October 16, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.