Upgraded investigation of the BOTSv3 dataset with framework mapping across MITRE ATT&CK, NIST CSF, NIST 800-53, and CIS Controls v8, documented SPL queries, and IOC artifacts.
Analyst: Umu Jalloh Dataset: Splunk Boss of the SOC v3 (BOTSv3) Attack Date: August 20, 2018 Investigation Type: Threat Hunting / Incident Response Tools Used: Splunk Enterprise, BOTSv3 Dataset Frameworks: MITRE ATT&CK, NIST CSF, NIST 800-53, CIS Controls v8
This is an investigation of a cryptocurrency mining attack against Frothly Brewing Company on August 20, 2018. I analyzed 1,944,092 events across 107 sourcetypes and uncovered a drive-by compromise through a trusted third-party brewing community website www.brewertalk.com. A malicious CoinHive JavaScript was injected into the website which silently hijacked employee browser resources to mine Monero cryptocurrency. The compromise originated from a misconfigured AWS S3 bucket that hosted brewertalk's code, which an internal postmortem email from brewertalk's administrator confirmed.
BSTOLL-L was the primary affected endpoint with sustained 100% CPU usage during the mining window. A second endpoint, BTUN-L, was exposed to the same attack vector but was successfully protected by Symantec Endpoint Protection, which blocked 46 JSCoinminer attempts. The contrast between the two hosts revealed a critical detection coverage gap on BSTOLL-L.
BOTSv3 contains multiple different attack threads on August 20, 2018. This investigation focuses on the CoinMiner drive-by compromise affecting BSTOLL-L. Other suspicious activity observed in the environment may relate to additional attack threads that are outside the scope of this report. Future investigations may address those threads separately.
| Component | Details |
|---|---|
| Organization | Frothly Brewing Company |
| Dataset | BOTSv3 - 1,944,092 events, 107 sourcetypes |
| Attack Date | August 20, 2018 |
| Mining Window | 09:37:50 - 10:04:11 (primary mining session) |
| Primary Victim Host | BSTOLL-L (user: bstoll, browser: Chrome) |
| Protected Host | BTUN-L (user: BillyTun, browser: Chrome and Edge) |
| Attack Vector | Drive-by compromise via brewertalk.com |
| Malware | JSCoinminer (JavaScript Monero miner) |
| C2 Infrastructure | coinhive.com |
I conducted this investigation with a hypothesis-driven method where each query was driven by a specific investigative question, and the results of each query informed the next.
The investigation followed seven phases:
- Phase 1 - Baseline Establishment - What data exists and when did suspicious activity occur?
- Phase 2 - Network Activity Analysis - What was the network doing during the attack window?
- Phase 3 - CPU Anomaly Investigation - Which endpoint was under abnormal resource pressure?
- Phase 4 - Payload Identification - What was the source of the malicious activity?
- Phase 5 - Detection Validation - Did security tooling detect the attack?
- Phase 6 - Timeline Reconstruction - When did each event occur and how do they correlate?
- Phase 7 - Root Cause Analysis - How was brewertalk compromised?
Investigative Question: What data sources are available and what is the volume of events?
index=botsv3
| stats count by sourcetype
| sort -count
Findings:
- 1,944,092 total events across 107 sourcetypes
- Top sourcetypes are syslog (283,976), stream:ip (227,872), osquery:results (219,997), and stream:dns (218,456)
- Symantec Endpoint Protection logs are present
- AWS sourcetypes confirmed that cloud infrastructure is in scope
Investigative Question: Is there a specific time window where activity spiked abnormally?
index=botsv3
| bucket _time span=1h
| stats count by _time
| sort -count
Findings:
- Attack date confirmed to be August 20, 2018
- Before the attack, activity was nearly silent (under 300 events/hour from 00:00 to 04:00)
- Activity exploded at 05:00 with 371,193 events
- Two distinct spikes in activity at 05:00-07:00 and 09:00-11:00
- There was likely a phase transition at the 08:00 gap (37,844 events)
Note: Activity spiked across the whole environment. The CoinMiner attack happened within these windows but does not account for all of the activity observed.
Investigative Question: What kind of activity caused the spike?
index=botsv3 earliest="08/20/2018:05:00:00" latest="08/20/2018:12:00:00"
| bucket _time span=1h
| stats count by _time, sourcetype
| sort -count
Findings:
- Four sourcetypes fired at 05:00, suggesting coordinated multi-layer activity
- Beaconing behavior observed with stream:dns appearing across every attack hour
- PerfmonMk:Process spiked at 09:00 with 54,767 events, indicating heavy CPU on Windows endpoints
- Cloud activity escalated, aws:cloudwatchlogs spiked at 11:00 (114,913)
Two priority leads identified: DNS beaconing patterns and Windows CPU pressure.
Investigative Question: What domains was this network querying during the attack window?
index=botsv3 sourcetype="stream:dns"
earliest="08/20/2018:05:00:00" latest="08/20/2018:12:00:00"
| stats count by query
| sort -count
Findings:
- 218,456 DNS events across 3,984 unique domains
- splunk.froth.ly was queried 5,684 times, far above any other domain
- All other top domains were normal corporate traffic (Microsoft, Google, Office365)
Investigative Question: Which machines were responsible for the 5,684 queries?
Analyst Note: Initial query used src field which returned no results. Pivoted to host field after raw event inspection revealed the source IP is stored in the host field for stream:dns in this dataset.
index=botsv3 sourcetype="stream:dns"
earliest="08/20/2018:05:00:00" latest="08/20/2018:12:00:00"
query="splunk.froth.ly"
| stats count by host
| sort -count
Findings:
- 14 distinct hosts were querying splunk.froth.ly
- The counts were very similar across the 14 hosts which is a sign of automated beaconing
- Hosts include workstations and EC2 cloud infrastructure
While splunk.froth.ly initially appeared suspicious due to its very high query volume, my follow-up investigation did not connect this domain to the CoinMiner attack.
I pivoted from this lead to the second priority lead, the PerfmonMk:Process spike in Q03 which led me to uncover the actual mining activity on BSTOLL-L.
Investigative Question: Which Windows endpoint experienced abnormal CPU activity?
index=botsv3 sourcetype="PerfmonMk:Process"
earliest="08/20/2018:00:00:00" latest="08/20/2018:23:59:59"
| stats count by host
| sort -count
Findings:
- PerfmonMk:Process data only exists for BSTOLL-L with 864 events, with no events on other hosts
- I identified BSTOLL-L as primary host of interest
Visibility Note: This is a real visibility gap in the environment. I cannot confirm whether other hosts also experienced CPU pressure because there was no process-level performance monitoring on them.
Investigative Question: Which process on BSTOLL-L was consuming the most CPU?
index=botsv3 sourcetype="PerfmonMk:Process"
earliest="08/20/2018:00:00:00" latest="08/20/2018:23:59:59"
host="BSTOLL-L"
| stats max(%_Processor_Time) as max_cpu, avg(%_Processor_Time) as avg_cpu by instance
| sort -max_cpu
| head 20
Findings:
- Total CPU averaged 99.4% all day
- Chrome browser tab was consuming abnormal CPU with 100% max, 22.9% average
- Browser-based CPU at this level suggests malicious JavaScript execution
Investigative Question: What websites was Chrome connecting to during the CPU spike?
index=botsv3 sourcetype="stream:http"
earliest="08/20/2018:00:00:00" latest="08/20/2018:23:59:59"
host="BSTOLL-L"
| stats count by site
| sort -count
| head 30
Findings:
- www.brewertalk.com was visited the most with 137 requests
- Second-place was a normal certificate validation site (ocsp.digicert.com) with 42 requests
- All the other destinations were normal corporate or personal browsing
Investigative Question: What specific resources was Chrome loading from brewertalk?
index=botsv3 sourcetype="stream:http"
earliest="08/20/2018:00:00:00" latest="08/20/2018:23:59:59"
host="BSTOLL-L" site="www.brewertalk.com"
| stats count by uri_path, http_method, status
| sort -count
Findings:
- Standard forum resources loaded: /forumdisplay.php, /showthread.php, /index.php, theme CSS, jQuery, forum images
- No obvious malicious filenames in URI paths
- Suggests malicious JavaScript was either embedded in legitimate-looking files or loaded from a third-party domain
Investigative Question: What other domains was BSTOLL-L's browser contacting during the CPU spike?
index=botsv3 sourcetype="stream:dns"
earliest="08/20/2018:00:00:00" latest="08/20/2018:23:59:59"
host="BSTOLL-L"
NOT (query="*.microsoft.com" OR query="*.google.com" OR query="*.googleapis.com"
OR query="*.googleusercontent.com" OR query="*.gstatic.com" OR query="*.msedge.net"
OR query="*.live.com" OR query="*.office.com" OR query="*.office365.com"
OR query="*.officeapps.live.com" OR query="*.amazonaws.com" OR query="*.aws.amazon.com"
OR query="*.cloudfront.net" OR query="*.azureedge.net" OR query="*.skype.com"
OR query="*.bing.com" OR query="*.msn.com" OR query="*.sharepoint.com"
OR query="*.sharepointonline.com" OR query="*.facebook.com" OR query="*.facebook.net"
OR query="*.doubleclick.net" OR query="*.symantec.com" OR query="*.symantecliveupdate.com"
OR query="*.digicert.com" OR query="*.froth.ly" OR query="ipinfo.io")
| stats count by query
| sort -count
Findings:
- Found Coinhive.com with 4 requests after filtering out known legitimate corporate domains
- CoinHive was a notorious cryptocurrency mining service used in drive-by compromises
- This is the smoking gun. BSTOLL-L had a CPU spike because of cryptocurrency mining
Investigative Question: When did BSTOLL-L first query coinhive.com?
index=botsv3 sourcetype="stream:dns"
earliest="08/20/2018:00:00:00" latest="08/20/2018:23:59:59"
host="BSTOLL-L" query="coinhive.com"
| table _time, host, query, src, dest
| sort _time
Findings:
- First coinhive.com DNS query was 2018-08-20 09:38:19
- Second query was at 09:39:20
- 4 total queries captured at two different timestamps just a minute apart, then no further DNS activity. This suggests a WebSocket establishing a persistent connection
Investigative Question: Did Symantec Endpoint Protection detect any malicious activity?
index=botsv3 sourcetype="symantec:ep:security:file"
earliest="08/20/2018:00:00:00" latest="08/20/2018:23:59:59"
| table _time, _raw
| sort _time
Findings:
- 46 Symantec detections of "Web Attack: JSCoinminer Download 6/8" - all blocked
- All 46 detections were on BTUN-L, not BSTOLL-L
- Affected application: Chrome
- User: BillyTun
- This confirmed brewertalk.com as the source of malicious content and JSCoinminer as the malware
Investigative Question: How widespread was the malicious content on brewertalk.com?
index=botsv3 sourcetype="symantec:ep:security:file"
earliest="08/20/2018:00:00:00" latest="08/20/2018:23:59:59"
JSCoinminer
| rex field=_raw "Intrusion URL: (?<intrusion_url>[^,]+)"
| stats count by intrusion_url
| sort -count
Findings:
- 10 unique brewertalk URLs served the malicious script
- Affected pages included the homepage, multiple forum categories (fid=5, 7, 8, 9, 11), thread pages, and attachments
- This was a site-wide compromise of brewertalk, not isolated page injection
Investigative Question: Did Symantec detect anything on BSTOLL-L?
index=botsv3 sourcetype="symantec:ep:security:file"
earliest="08/20/2018:00:00:00" latest="08/20/2018:23:59:59"
BSTOLL-L
| table _time, _raw
| sort _time
Findings:
- Zero Symantec detections for BSTOLL-L despite having similar exposure to the attack vector
- Either Symantec was not running, signatures were outdated, or it was failing silently
- This explains why BSTOLL-L was the actual mining victim while BTUN-L was protected
Investigative Question: Did any other host query coinhive.com?
index=botsv3 sourcetype="stream:dns"
earliest="08/20/2018:00:00:00" latest="08/20/2018:23:59:59"
query="coinhive.com"
| stats count by host
| sort -count
Findings:
- Only BSTOLL-L queried coinhive.com, no other host did
- Confirms BSTOLL-L was the only successful mining victim
Investigative Question: When did BSTOLL-L first visit brewertalk?
index=botsv3 sourcetype="stream:http"
earliest="08/20/2018:00:00:00" latest="08/20/2018:23:59:59"
host="BSTOLL-L" site="www.brewertalk.com"
| table _time, host, site, uri_path
| sort _time
| head 5
Findings: First HTTP request to brewertalk was on 2018-08-20 09:07:23
Investigative Question: When did Symantec first detect JSCoinminer?
index=botsv3 sourcetype="symantec:ep:security:file"
earliest="08/20/2018:00:00:00" latest="08/20/2018:23:59:59"
JSCoinminer
| table _time, _raw
| sort _time
| head 5
Findings: First JSCoinminer block on BTUN-L was 2018-08-20 09:37:40
Investigative Question: When did Chrome's CPU climb to 100% and how long did the mining sustain?
index=botsv3 sourcetype="PerfmonMk:Process"
earliest="08/20/2018:09:00:00" latest="08/20/2018:11:30:00"
host="BSTOLL-L" instance=*chrome*
%_Processor_Time>=99
| table _time, instance, %_Processor_Time
| sort _time
Findings:
- 132 total events at 99-100% CPU (131 in the sustained mining session plus 1 isolated event at 10:59:19)
- First mining event: 2018-08-20 09:37:50 (chrome#5)
- Sustained mining session: 09:37:50 to 10:04:11 (~26 minutes)
- Final isolated event: 10:59:19
- No further mining activity for the remainder of the day
Investigative Question: What does the full Chrome CPU pattern look like across the attack window?
Reasoning: Q18 captured precise timestamps of high-CPU events (>=99%) but doesn't show the broader pattern including baseline activity. Visualizing the unfiltered data reveals the contrast between normal CPU and mining periods.
index=botsv3 sourcetype="PerfmonMk:Process"
earliest="08/20/2018:09:00:00" latest="08/20/2018:11:30:00"
host="BSTOLL-L" instance=*chrome*
| table _time, instance, %_Processor_Time
| sort _time
Findings:
- The mining session shows up as a dense block of sustained 100% CPU between baseline activity
- The brief 10:59:19 spike stands out clearly as an isolated event after mining stopped
Investigative Question: How are the 132 high-CPU events distributed across chrome process instances?
Reasoning: Q18 returned a raw event count. PerfmonMk:Process samples every running process every second, so simultaneous samples across multiple chrome instances can be counted as separate events for a single moment of activity. Deduplicating by timestamp and instance shows the true distribution.
index=botsv3 sourcetype="PerfmonMk:Process"
earliest="08/20/2018:09:00:00" latest="08/20/2018:11:30:00"
host="BSTOLL-L" instance=*chrome*
%_Processor_Time>=99
| dedup _time, instance
| stats min(_time) as first_seen,
max(_time) as last_seen,
count by instance
Findings:
- The 132 events are distributed across two chrome instances: chrome#4 (129 events) and chrome#5 (3 events)
- chrome#4 produced the sustained mining session from 09:38:30 to 10:04:11
- chrome#5 produced the earliest 99%+ event at 09:37:50 and the isolated late event at 10:59:19
Investigative Question: How was brewertalk compromised?
Reasoning: Search SMTP logs for brewertalk-related communications. Internal Frothly emails about brewertalk may contain evidence of how the compromise occurred.
SPL:
index=botsv3 sourcetype=stream:smtp brewertalk
Findings:
11 SMTP events returned, forming a complete timeline of the brewertalk incident:
- 9:03 AM: Bud emails Mallory privately: "I'm making some great changes to brewertalk! Stay tuned."
- 9:06 AM: Bud announces brewertalk improvements to allhands, mentions AWS environment
- 9:09 - 9:16 AM: Frothly users (Fyodor, Peat) report site errors and registration issues
- 9:49 AM: Billy Tun reports brewertalk and his machine running slow
- 9:50 AM: Bud responds: "I haven't figured it out yet"
- 9:56 AM: Bud identifies the issue: Chrome CPU spiked to 100%, "malicious code got into our forums"
- 10:24 AM: Bud sends postmortem to allhands explaining the root cause
The 10:24 AM postmortem email body was base64-encoded. After decoding with CyberChef, Bud confirms the root cause: he accidentally left an AWS S3 bucket publicly writable. Attackers found the open bucket, modified brewertalk's JavaScript code to inject CoinHive, and every visitor to brewertalk.com downloaded the miner.
From the decoded email:
Well, I messed up!
I had a "open public bucket" accidentally. It looks like some malicious people got into our code and added in something called a "coinminer" which made it so that anyone browsing to our site would generate some cryptocurrency. That's why some browsers were hitting 100% CPU!
I closed down the bucket and cleaned up the code, and will bring brewertalk back on line soon.
Sorry Grace!
-buuuuuuddddddd ☹
Root cause: misconfigured AWS S3 bucket with public write access.
| Time | BSTOLL-L (Chrome) | BTUN-L (Chrome and Edge) | Significance |
|---|---|---|---|
| 09:07:23 | First visit to brewertalk.com | - | Compromise begins on BSTOLL-L |
| 09:37:40 | - | First Symantec block of JSCoinminer | Defense succeeds on protected host |
| 09:37:50 | First Chrome 100% CPU event (chrome#5) | - | Mining payload begins executing |
| 09:38:19 | First coinhive.com DNS query | - | Mining script connects to pool |
| 09:39:20 | Additional coinhive.com queries (4 total) | - | Mining handshake complete |
| 09:37:50 - 10:04:11 | Sustained 100% CPU mining on chrome#4 (~26 minutes, 129 events) | Symantec blocks 46 attempts | Peak attack window |
| 10:04:11 | Last 100% CPU event of primary mining session | - | Mining session ends |
| 10:04 - 10:59 | Chrome CPU drops to baseline | - | Mining inactive |
| 10:59:19 | Final isolated chrome#5 100% CPU event | - | Last mining event of the day |
CPU spike correlates with brewertalk visits. Chrome CPU was at baseline (under 1%) prior to brewertalk activity. CPU climbed during browsing and hit 100% during sustained brewertalk activity.
Same attack, different outcomes. Symantec on BTUN-L blocked the JSCoinminer attempt at 09:37:40. 10 seconds later, Chrome on BSTOLL-L hit 100% CPU and began mining. 39 seconds after Symantec's block, BSTOLL-L's browser successfully connected to CoinHive infrastructure. Two machines were attacked by the same vector but had opposite outcomes due to detection coverage gaps.
Mining duration was approximately 26 minutes on chrome#4. Chrome process instance chrome#4 sustained 99-100% CPU usage from 09:38:30 to 10:04:11, producing 129 distinct sample windows. The second chrome instance (chrome#5) contributed 3 additional 99%+ CPU events, including the earliest mining event at 09:37:50 and a final isolated event at 10:59:19.
- Brewertalk.com served malicious JSCoinminer JavaScript - confirmed by Symantec naming the URL as the intrusion source
- BSTOLL-L was the actual mining victim - sustained 100% CPU for 26 minutes, coinhive.com DNS confirmed, no Symantec protection
- BTUN-L was successfully protected - Symantec blocked 46 attempts at the same attack vector
- A detection coverage gap on BSTOLL-L enabled the mining attack to succeed
- Root cause was a misconfigured AWS S3 bucket - brewertalk's code was hosted in a publicly writable S3 bucket which allowed attackers to inject CoinHive into the JavaScript.
This section maps the investigation findings to industry frameworks covering attacker techniques (MITRE ATT&CK), defensive countermeasures (MITRE D3FEND), and security controls (NIST and CIS).
| Technique | Tactic | Evidence |
|---|---|---|
| T1189 Drive-by Compromise | Initial Access | Symantec logs identified multiple URLs as the intrusion sources, indicating site-wide compromise (Q12, Q13) |
| T1059.007 Command and Scripting Interpreter: JavaScript | Execution | Symantec signature "JSCoinminer Download" confirmed JavaScript-based payload executing in Chrome browser (Q12) |
| T1071.001 Application Layer Protocol: Web Protocols | Command and Control | DNS query to known C2 domain coinhive.com (Q11) combined with sustained mining activity (Q18) indicates the JSCoinminer payload established C2-communication with mining pool infrastructure. Direct WebSocket traffic was not captured in the dataset's HTTP logs but is inferable from the activity pattern. |
| T1496 Resource Hijacking | Impact | PerfmonMk:Process showed Chrome on BSTOLL-L sustained 100% CPU during attack window (Q07, Q18, Q19) |
| ATT&CK Technique | D3FEND Countermeasure |
|---|---|
| T1189 Drive-by Compromise | D3-WHL Web Header Logging, D3-NTA Network Traffic Analysis |
| T1059.007 JavaScript | D3-PSEP Process Self-Modification Detection |
| T1071.001 Application Layer Protocol: Web | D3-DNSAL DNS Allowlisting, D3-DNSDL DNS Denylisting |
| T1496 Resource Hijacking | D3-PR Process Restriction, D3-RAPA Resource Access Pattern Analysis |
| Function | Subcategory | Evidence |
|---|---|---|
| Detect (DE.AE) Anomalies and Events | DE.AE-2 - Detected events analyzed to understand attack targets | Q03 surfaced PerfmonMk and DNS anomalies; Q04-Q05 traced DNS beaconing scope; Q07 identified abnormal CPU |
| Detect (DE.CM) Security Continuous Monitoring | DE.CM-4 - Malicious code is detected | Symantec EP detected 46 JSCoinminer attempts on BTUN-L (Q12) |
| Respond (RS.AN) Analysis | RS.AN-1 - Notifications from detection systems are investigated | This investigation traced the complete attack chain using log data across multiple sourcetypes |
| Control | Evidence |
|---|---|
| SI-3 Malicious Code Protection | Symantec EP successfully blocked malicious code on BTUN-L. Detection gap on BSTOLL-L allowed mining to proceed (Q12, Q14) |
| SI-4 System Monitoring | PerfmonMk:Process, stream:dns, stream:http, and Symantec sourcetypes provided the visibility necessary to reconstruct the attack |
| Control | Evidence |
|---|---|
| Control 8 Audit Log Management | Investigation was made possible by properly retained logs across DNS, HTTP, endpoint performance, and security tooling |
| Control 9 Email and Web Browser Protections | Drive-by compromise occurred through web browser; the malicious script ran inside Chrome on BSTOLL-L without blocking |
| Control 10 Malware Defenses | Symantec EP partially effective - protection worked on BTUN-L, failed on BSTOLL-L (Q12, Q14) |
| Control 13 Network Monitoring and Defense | DNS-level monitoring captured the coinhive.com query that confirmed C2-equivalent communication (Q11) |
Direct cost. Sustained 100% CPU mining on BSTOLL-L for 26 minutes increased electricity consumption beyond baseline and accelerated hardware wear on the affected processor. The direct cost for a single workstation is small but compounds with the number of affected hosts and mining duration.
Productivity impact. The user on BSTOLL-L worked on a machine running at 100% CPU for 26 minutes, plus the isolated late event at 10:59:19. Browser performance, application responsiveness, and any work requiring CPU resources would have been degraded during this window.
Compliance impact. Cryptomining is unauthorized use of corporate computing resources. If BSTOLL-L touched regulated data, several frameworks could be triggered: PCI DSS Requirement 5.1 (anti-malware controls), HIPAA 164.308(a)(6) (security incident response procedures), and SOX controls if financial data was processed on the host. This investigation did not establish what data classification existed on BSTOLL-L.
Reputational risk. Unauthorized cryptomining on corporate infrastructure can trigger breach notification obligations under GDPR, state breach laws, and sector regulations if customer data was on the affected host. For Frothly Brewing, public disclosure carries an additional cost: the attack vector was brewertalk.com, a trusted forum in the brewing community. An incident becoming public could damage Frothly's standing with the same industry network they rely on for customer engagement and supplier relationships.
- stream:dns source field issue -
srcfield was empty so I usedhostfield instead after checking raw events. - PerfmonMk visibility gap - Process performance data was only collected on BSTOLL-L. Other endpoints could not be assessed for similar CPU anomalies.
- Multiple investigative threads - DNS beaconing and CPU pressure were both followed. The DNS lead (splunk.froth.ly) did not connect to the CoinMiner attack. The CPU lead led directly to the mining activity and BSTOLL-L.
- PerfmonMk event counting needed deduplication - The initial Q18 analysis reported 131 events in the mining session plus 1 isolated event. PerfmonMk:Process samples every running process every second, so a single high-CPU moment can be counted multiple times when multiple chrome processes are sampled together. Re-running the query with
| dedup _time, instanceshowed the mining was actually distributed across two chrome instances: 129 events on chrome#4 (the sustained mining window) and 3 events on chrome#5 (including the earliest event at 09:37:50 and the isolated 10:59:19 event). - Email body required external decoding - The postmortem email body in stream:smtp was base64-encoded across multiple MIME parts. Had to extract the base64 string from Splunk's content field and decode it with CyberChef (From Base64).
- Address Symantec coverage gap on BSTOLL-L - Investigate why JSCoinminer was not detected and ensure consistent protection across all endpoints
- Deploy uniform endpoint performance monitoring - PerfmonMk should collect from all Windows endpoints, not just BSTOLL-L
- Block known cryptocurrency mining domains - Implement DNS-layer blocking for coinhive.com and similar mining infrastructure
- User awareness training - Educate employees on drive-by compromise risks, even on trusted industry websites
- Web filtering - Implement URL filtering to block known high-risk site categories
- Incident response runbook - Create documented procedure for cryptomining detection and response
- Third-party risk assessment - The attack vector was a trusted industry website employees regularly accessed. Review security posture of external sites used for work
README.md- This investigation narrative with embedded SPL queries and screenshotsIOCs.md- Indicators of compromise from this investigationqueries/- Individual SPL files for each investigation query and proposed detection rulescreenshots/- Visual evidence supporting each querysetup/- Environment setup documentation
Investigation conducted by Umu Jalloh Cybersecurity & Computer Forensics Student | Stark State College Cybersecurity Intern, Ohio Cyber Range Institute CompTIA Security+ | CompTIA Network+