Detection proposal: VBA Stomping (T1564.007) - EvilClippy execution and vbaProject.bin creation by non-Office process

Open
  • Is something wrong?
#4,405 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@ali-vrd is already working on this.

Since Nov 10, 2026.

  • #4406 by @ali-vrd — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
54/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Domain
backend, security

Research direction

Start by checking the detection conventions under detections/ on develop and the equivalent SigmaHQ proposal, then identify the ESCU format and review process for new detections. The issue specifies two analytics: EvilClippy process execution and non-Office, non-archiver creation of vbaProject.bin. Done means submitting both SPL detections with naming, status, and analytic story placement aligned to maintainer guidance; attack data and tests need maintainer direction.

Written by the indexing model from the issue text.

Description

Hi team! 👋

I would like to contribute two new detections for VBA Stomping (T1564.007, Defense Evasion). As of today ESCU has no detection covering this technique (verified against detections/ on develop).

Background: VBA stomping removes the VBA source code from an Office document while keeping the compiled p-code, so the macro still executes but the malicious source is invisible to static analysis tools and even the VBA editor. EvilClippy (Outflank) is the best-known open-source tool implementing this technique. MITRE reference: https://attack.mitre.org/techniques/T1564/007/

Proposed detections:

  1. EvilClippy execution - Endpoint.Processes datamodel, process_name/original_file_name = EvilClippy.exe (Sysmon EID 1 / Security 4688 / EDR telemetry)
  2. vbaProject.bin creation by a non-Office process - Endpoint.Filesystem datamodel, file_name = vbaProject.bin where the creating process is NOT an Office application (WINWORD/EXCEL/POWERPNT/MSACCESS/OUTLOOK/...) and not a common archiver (7z, WinRAR, Bandizip), since a legitimately saved macro project is always written by the Office host process (Sysmon EID 11)

Prior art: I have just submitted equivalent coverage to SigmaHQ (SigmaHQ/sigma#6595) and would love to port it to SPL for ESCU.

Attack data: I could not find EvilClippy or vbaProject datasets in splunk/attack_data, so the initial PR will not include unit tests. I am happy to help record/generate attack data if maintainers point me to the preferred process, or the team can generate it with attack_range as usual.

CLA: I am completing the individual contributor agreement now and will confirm it in the PR.

Happy to adjust naming, status, and analytic story placement per maintainer feedback. Thanks!

Dominant language
Python
Stars
1.7k
Forks
507
Avg merge
2d 17h
Merged PRs (30d)
35

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from splunk/security_content

All issues in splunk/security_content

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.