Examine suspicious files and watch payment identifiers without leaving your environment.
Vigil reads a submitted file on your own instance and describes what it contains, checks it against installed YARA detection rules and reports what public reputation sources already know about its hash. Separately, merchant and terminal identifiers, BIN ranges and trading names are watched across monitored underground sources and infostealer data.
Questions that arrive faster than the answers
An attachment or download that nobody wants to open
Sending the file to a third-party service may not be acceptable for confidentiality reasons, and a hash lookup returns nothing when the file is new.
Payment identifiers circulating before fraud appears
Merchant IDs, terminal IDs and portal logins captured by infostealer malware can be traded or posted well before the acquirer’s fraud controls detect misuse.
Payment-themed look-alikes of your domain
Domains built around payment, invoice or checkout wording may be registered to imitate a customer-facing service and require early review.
How Vigil handles it
Two questions about a file — what is known about it, and what is inside it — and continuous watching of the identifiers that matter to payment operations. Nothing is executed and files are not retained.
- 01 · Look up
Hash reputation
The file’s MD5, SHA-1 or SHA-256 hash is checked against public reputation sources; the file itself never leaves your machine.
- 02 · Read
Static analysis on your instance
Headers, sections, imported functions, readable text and embedded network addresses are described. The file is not executed and is not kept; only its hashes and the observations are stored.
- 03 · Match
YARA detection rules
The installed rule set is applied on your instance. A match is reported with the rule’s name, author, reference and the exact location in the file. Additional rules can be installed for your instance on request.
- 04 · Watch
Payment identifiers and look-alikes
Merchant and terminal identifiers, BIN ranges and trading names are matched as whole words across monitored sources and infostealer captures; payment-themed look-alike domains are reported alongside.
Hash lookup, file analysis and the stored results of earlier analyses, including the YARA outcome for each file.
What changes for your team
A first answer about a file within seconds
Analysts can describe a suspicious file and check it against detection rules before deciding whether deeper analysis is warranted.
Confidential files stay in your environment
Static analysis and rule matching run on your instance; no sample is uploaded to a third party.
Earlier notice of exposed payment identifiers
Identifiers seen in monitored sources are raised as findings with source context, before misuse is visible in transaction data.
Questions we get asked
Is this a sandbox?+
No. Static analysis reads and describes the file; it does not run it. Observing behaviour requires detonation in an isolated sandbox, which this platform does not operate.
Which YARA rules are used?+
A curated public rule set is installed by default; it can be replaced or extended for your instance on request. Rules that use features the engine does not support are listed as not applied rather than silently ignored.
Can the platform see or block card transactions?+
No. It reports identifiers and logins that have leaked; transaction monitoring and blocking remain with your acquirer and payment provider.
Review file analysis and payment-identifier monitoring.
Review representative analyses and the identifier-watch workflow. Customer-specific configuration is performed only after scope and authorisation are confirmed.