sublime-rules is a curated open-source rule repository from Sublime Security for detecting and preventing BEC, malware, and credential phishing attacks in authorized email security operations.
| Tool | sublime-security/sublime-rules — open-source detection and prevention rules for the Sublime email security platform |
| Category | Email security detection content (YAML rule feeds) |
| Primary Use | Deploying community-maintained rules against BEC, credential phishing, malware, and attachment-based attacks via MQL |
| Safe Use | Purely defensive: designed for security teams defending their own mail environments, threat hunters, and detection engineers operating with explicit authorization |
| Telemetry Note | Not applicable as an offensive tool; as detection content, its rules generate alerts and verdicts inside Sublime, giving defenders structured visibility into matched messages |
sublime-rules is the official open-source rule repository published by Sublime Security, and it occupies an unusual and valuable niche in the security tooling landscape: rather than being a tool that simulates attacks, it is pure defensive content. The repository contains community-maintained detection and prevention rules for the Sublime email security platform, targeting the categories of email-borne threats that dominate real-world incident statistics — business email compromise (BEC), malware delivery, and credential phishing. For defenders, this is the kind of upstream detection engineering content that usually lives behind a vendor paywall, published here under an MIT license.
The rules are written in YAML, which is the repo's declared language and matches how Sublime detection content is structured. Each rule is a standalone file in the repository — the README links directly to examples like attachment_lnk_file_with_embedded_content.yml and attachment_with_encrypted_zip_unsolicited.yml, which reveals a file-per-detection layout under a detection-rules/ directory. This structure matters operationally: detection engineers can diff, review, cherry-pick, and version-control individual rules rather than ingesting an opaque feed, which is exactly the workflow mature security teams want for detection-as-code practices.
The example categories listed in the README map neatly onto current attacker tradecraft. HTML smuggling rules address the technique where malicious payloads are decoded client-side from encoded content inside otherwise benign-looking HTML attachments. There are rules for VIP and executive impersonation, the core mechanic of most BEC campaigns, where the sender display name or domain similarity is engineered to trick recipients. Attachment-focused detections cover malicious OneNote files — a delivery vector that spiked in real campaigns — and LNK files with embedded content, a classic shortcut-abuse pattern. A dedicated rule targets unsolicited encrypted ZIP archives, which attackers use to evade gateway scanning while socializing the password to the victim in the message body.
What makes the repository more than a static rule dump is the underlying query language. Rules for Sublime are expressed in MQL, the Message Query Language, and the README links to a full MQL reference in the project documentation. MQL gives analysts structured access to message internals — headers, attachment properties, body content, and metadata — so the rules can express conditions that are difficult or impossible in traditional header-only filtering. For a detection engineer, the practical implication is that these rules are readable, auditable logic rather than black-box heuristics, and they serve as a corpus of worked examples for learning to write custom MQL detections.
The repository is not the platform itself. The README points to sublime-platform, the open-source project the rules run on, and to Sublime Cloud, a managed offering with a free tier for evaluation. This separation between engine and content is architecturally sound: the community can improve detection logic independently of platform releases, and organizations running self-hosted Sublime deployments can subscribe to rule updates on their own cadence. The release log and the vendor blog serve as the changelog channel for new detections and capabilities.
Beyond the official feed, the README curates a list of community rule feeds, which effectively turns sublime-rules into the hub of a small ecosystem. Third-party feeds from DelivrTo (delivr-to/detections), vector-sec (vector-sec/public-sublime-rules), and amitchell516 (aidenmitchell/custom-sublime-rules) extend coverage with detections written by independent practitioners and security firms. This is worth noting for assessment purposes: layering multiple community feeds gives broader tradecraft coverage, but each third-party rule should be reviewed before production deployment since community content varies in quality and false-positive characteristics.
The repository's metadata reinforces its serious, production-oriented character: 374 stars, topics of email-security, phishing, and threat-hunting, and an MIT license that permits unrestricted internal use and modification. The topic tagging is accurate to the content — the rules serve both inline prevention and retrospective threat hunting, since a rule that blocks a message pattern can also be run in detection-only mode over historical mail to quantify exposure. That hunt angle is underappreciated: deploying this corpus against a mailbox archive can surface how long a technique has been hitting the environment and whether any prior messages slipped past existing controls.
For authorized defenders, the integration story is straightforward. A team standing up email security coverage would deploy the Sublime platform (self-hosted or cloud), pull this ruleset as the baseline detection corpus, then tune the individual YAML rules against their own mail flow to manage false positives — executive impersonation rules in particular need thresholding per organization. The encrypted ZIP rule, for example, explicitly scopes to unsolicited mail, a qualifier that hints at the rule-logic sophistication: legitimate encrypted archives from known senders should not trip it. Reviewing those scoping decisions inside each rule file is the best fast-track education the repo offers.
There is nothing in this repository to caution against from a policy perspective — it is unambiguously defensive tooling. The only operational caveats are ordinary ones: community detection content ages against evolving attacker techniques, so teams should monitor the release log, and third-party feeds deserve the same code review discipline as any other content entering a production security pipeline. As a public good, sublime-rules doubles as a readable taxonomy of current email attack techniques, which makes it useful reading even for analysts whose organizations run different mail security stacks.
sublime-security/sublime-rules.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.