Sector ISAC Report on Silent Borealis
Your sector ISAC publishes a report on 'Silent Borealis,' a financially motivated actor targeting logistics firms. The report rates confidence as moderate and lists five IPs and three domains, some 90 days old, plus TTPs: phishing with ISO attachments, certutil -urlcache for download, bitsadmin for persistence, C2 over legitimate cloud storage, and Kerberoasting. Your company has 2,500 endpoints, EDR, web proxy, NetFlow, and a small SOC with no NDR and no UEBA. The CISO wants to know what to deploy in the next 30 days and whether to block all IOCs. The SOC has 1.5 FTE threat hunters and a SIEM with 90-day retention. The report says the actor often waits 30-60 days before lateral movement.
1. How would you evaluate the intel's confidence and decide which IOCs to operationalize?
Read the worked answer
Moderate confidence and 90-day-old IOCs mean the atomic indicators have limited shelf life. The actor likely rotates IPs and domains, and the ISAC may have shared them after the campaign peaked. Treat the IPs and domains as short-lived blocking candidates, not as detection strategy. Operationalize them at the proxy and firewall with expiry dates, logging, and an owner, and check them against current traffic before blocking to avoid collateral damage from shared cloud hosting.
The TTPs are more durable and deserve the detection investment: ISO attachment delivery, certutil -urlcache, bitsadmin, cloud-storage C2, and Kerberoasting. Validate each against available telemetry. If the SOC cannot monitor Kerberoasting because it lacks Windows event forwarding, that is a coverage gap, not an IOC problem. Share back any sightings to the ISAC. The decision rule is: block IOCs cheaply and temporarily, but build detections on behaviors that survive indicator rotation.
2. Prioritize three detections to build in 30 days, with data sources and rationale.
Read the worked answer
1. certutil and bitsadmin command-line detection. Use EDR process telemetry to alert on certutil -urlcache -split -f and bitsadmin /transfer with external URLs, especially from Office or browser parents. This is high value because the behavior is specific and the data already exists.
2. Kerberoasting detection. Forward Windows 4769 events and alert on RC4-encrypted service-ticket requests for accounts with SPNs, particularly bursts from one host. This addresses the actor's credential-access stage and uses existing domain logs if forwarding is fixed.
3. Cloud-storage C2 via proxy and NetFlow. Detect unusually regular HTTPS sessions to cloud-storage categories from servers or non-browser processes, plus large uploads outside baseline. This is harder and noisier, so start with hunting queries rather than paging alerts.
Rationale: with 1.5 FTE, prefer detections that are specific, low-maintenance, and mapped to known actor stages. Do not build five detections at once; tune each for a week and document false positives.
3. What threat-hunting hypothesis would you run first, and what would success look like?
Read the worked answer
Run: 'Silent Borealis used ISO attachment phishing to gain initial access, then executed certutil or bitsadmin from a user-writable directory.' Search email gateway and endpoint telemetry for ISO or IMG attachments delivered in the last 90 days, then pivot to EDR for certutil, bitsadmin, and child processes from mounted ISOs. Check proxy logs for the listed domains and for cloud-storage uploads from the same hosts.
Success is not only finding a compromised host. A valid outcome is proving the hypothesis false for the available data and documenting the coverage gap that prevents certainty, such as missing email attachment metadata or no PowerShell script-block logging. If the hunt finds a hit, escalate to incident response and preserve memory before remediation. If it finds nothing, add the queries to scheduled detection and report residual risk to the CISO. The hunt should produce a reusable query and a clear statement of confidence.