Focused Solution · E-ITDR
Silver Fox trojan
detection and investigation
Silver Fox style trojans arrive disguised as everyday office and tax software, and variants turn over faster than any single sample signature can follow. This solution investigates in three layers: intelligence covers known samples, behavioural clues point at how it landed and how it talks out, and identity activity answers whether one infected machine has spread any further.
Where It Lands
It is aimed at people, not at systems
This family arrives disguised as everyday office and tax software: an "invoicing tool update", a "notice attachment" — opening it is all the landing takes. The way in is a person, so the machines that fall first are usually in finance, administration and operations: the ones running tax, invoicing and banking clients, and the ones least able to afford downtime.
This page is organised around publicly observable behaviour of the family and cites no unsourced sample counts, variant rates or incident statistics. Whether a specific sample matches is decided by the current intelligence and rule catalogue, not by the behavioural description here.
Three Layers
Intelligence, behaviour, identity: what each can answer
The three layers are not simply three lines of defence stacked up; they are three different kinds of grounds. They are written separately because their certainty differs: intelligence is definite but lags, behaviour is general but depends on collection, and identity is the most stable but only appears once the attacker starts reaching other machines.
- Hashes and signing characteristics of known samples
- Known C2 infrastructure and domain entries
- A hit names the family, and cites the entry it came from
- How it landed, how it persists, how it talks out
- Independent of the sample, dependent on collection level
- Narrows the field; rarely names a family on its own
- Authentication and cross-host execution after credentials are taken
- Independent of the family; the most stable grounds
- Only appears once lateral movement begins
Coverage of unknown variants is not promised. The intelligence layer covers known samples and known infrastructure. Before intelligence catches up with a new variant, the behaviour layer can narrow the field and the identity layer can reveal spread — but what those two produce is a lead, not a family attribution. Treating "behavioural detection finds unknown variants" as a promise is a debt that comes due in a real incident.
All three depend on collection: the behaviour and identity layers rest on the endpoint's collection level, run-time permissions and audit policy. The same grounds produce nothing at all on a machine where collection is off; that difference is visible in collection health and is never filled in by inference.
Clues
Landing, persistence, traffic: each clue labelled
Review each behaviour, detection basis, platform and collection prerequisite. Rule matches and correlated evidence support investigation; specific techniques and samples require validation in the agreed environment.
| Clue | What is observed | What E-ITDR judges on | Platform and prerequisites | Status |
|---|---|---|---|---|
| Disguised delivery | An installer dressed as familiar software is run by the user | Known sample hashes and signing characteristics; abnormal file execution | Windows; process collection and file hash comparison | Rule in catalogue |
| In-memory loading | Core modules run in memory, leaving no complete file on disk | Abnormal writes to process memory and abnormal module loads | Windows; needs ETW process collection, invisible at lower levels | Depends on collection |
| Scheduled task persistence | A scheduled task is created with a name imitating a system component | Task creation records: name, creator, execution path and trigger | Windows; scheduled task collection | Rule in catalogue |
| Registry autostart | An autostart entry is written so it launches at logon | New and changed autostart key values | Windows; registry collection | Rule in catalogue |
| Service creation | A system service is registered for start-up | Service creation and configuration change records | Windows; service collection | Rule in catalogue |
| Credential theft | Browser credential stores are read; system credentials are exported | Abnormal access to credential stores and process memory; abnormal reads of credential store files | Windows; credential access rules available, credential file reads need generic file collection | Depends on collection |
Three things are not evidence of anything on their own: general-purpose tunnelling tools are used in plenty of legitimate operations; a shared cloud egress address has a great deal of normal business behind it; and normal software also names its tasks after common system components. A verdict comes from reading this process, this path, this creator and everything else that happened in that window together — never from blocking a brand list or a cloud address range wholesale, which mostly blocks legitimate business.
This table lists rules and collection evidence available for investigation. Validate specialist coverage against the product version, samples and collection conditions; it does not promise detection of every technique or variant.
Spread
Once one machine falls, find out whether it went further
The first two layers answer what happened to this machine; this one answers which other machines are involved. The grounds have nothing to do with the family — an attacker using stolen credentials to reach another host leaves exactly what any lateral movement leaves.
The correlation marks which links have direct evidence, which are inference, and which are missing because collection did not reach them. Egress quantification is a network-layer statistic; it does not identify sensitivity from file content, and one outbound connection does not confirm a data breach — nor can a file count be turned into a number of affected people or records. How this is stated externally is determined by the organisation under applicable law.
Response
Six stages, and who owns each one
Handling this kind of incident spans endpoint, network, mail and business. Saying who executes matters more than saying what is possible — when ownership is unclear, containment stalls at the authorisation step.
| Stage | E-ITDR | Executed by |
|---|---|---|
| Confirm | Supplies the alert, the grounds and the list of hosts involved | A SOC analyst confirms whether the conclusion holds |
| Contain | Isolates a host or stops a process under authorisation and approval, reporting status | Whether to isolate is decided jointly by the business and the response process |
| Eradicate | Handles files and collects evidence under authorisation | The scope of removing persistence and remnants is set by the response process |
| Block traffic | Supplies the outbound targets and the processes behind them | Domain and address blocking runs on the network side; delivery is narrowed at the mail gateway |
| Credentials | Not executed on your behalf | Browser and system credential resets are done in the identity system and by the user |
| Notify and report | Provides an exportable evidence set and file access records | External notification and wording are determined by the organisation under applicable law |
High-risk actions require role permissions, approval and review, and depend on the agent being online and the command channel reachable. A receipt may say success, failure or timeout; success does not mean the threat is gone. And one more: reimaging an endpoint destroys the evidence on it, so forensics comes first — the step most often skipped in a real incident.
Intelligence Scope
What the intelligence covers, and how it is updated
Intelligence is the part of a solution like this that is most easily oversold. Three things only: where it comes from, what it covers, and when it stops working.
An intelligence hit says "this matches a known entry". That is the start of a verdict, not the end of one: it still has to be read together with the rest of what happened on that machine, particularly when the only thing matched is an infrastructure address.
Validation
One agreed endpoint, all three layers checked
Validation is done layer by layer, because the criteria differ: intelligence is judged on whether it hits and cites its entry, behaviour on whether the clue can be explained, identity on whether spread is found. Objectives and results are recorded separately.
| Case | Test objective | Actual result |
|---|---|---|
| Intelligence hit | Run a known sample on the agreed endpoint; check the entry is matched and carries a source and effective version | To be measured |
| Landing and persistence | Check that alerts for scheduled tasks, autostart entries and service creation carry name, creator and execution path | To be measured |
| Outbound clues | Check that the outbound process and its target are recorded, and what is actually visible on this platform | To be measured |
| Credential theft | Reproduce a credential read; check an alert fires and the grounds can be explained | To be measured |
| Spread | Authenticate to a second host with the credential taken; check the cross-host correlation holds | To be measured |
| Authorised response | Run one isolation or forensic action; check the receipt and the re-test | To be measured |
This site publishes no complete operating commands and carries out no live attack execution; anything involving a live sample runs in an isolated environment, within a scope both sides agree beforehand. The cases exist to draw an authorised test scope and acceptance criteria together.
Record the collection prerequisites alongside the results (run-time permissions, audit policy, collection level) — the same case under different collection conditions produces results that cannot be compared. No detection-rate or variant-coverage figures are reported until testing is complete. What the demonstration environment shows is a product demonstration scenario, not any customer's actual incident record.
Expert Consultation
Start from one suspect endpoint and settle how far it went
Tell us how your endpoints are built, where the office and finance systems sit, and what you are seeing, and we will go through the three layers: what can be established, which collection prerequisites it needs, and where we make no promise yet:
Clue-by-clue review
Grounds and prerequisites for landing, persistence and traffic
Scope of the spread
How identity activity and lateral movement are investigated
Response responsibilities
What the platform executes and what other systems must do
Scan with Feishu to consult