YARA, threat intelligence, and web shell detection are three topics I had heard repeatedly throughout cybersecurity training. I understood them individually, but I had never seen how they worked together during an investigation.

While working through the Threat and Vulnerability Management module, I encountered a scenario involving suspicious files discovered on a web server. At first glance, it appeared to be a simple malware detection exercise. However, the investigation quickly evolved into something much more realistic. Instead of simply accepting what automated tools reported, I had to verify findings, investigate inconsistencies, and build confidence in my conclusions using multiple sources of evidence.

This write-up documents my investigation process, the challenges I encountered, and how YARA, Loki, and threat intelligence helped identify a malicious web shell.

Scenario Overview

As a SOC analyst, I was provided with suspicious files recovered from a web server. The objective was to determine whether the files were malicious, identify their purpose, and understand whether additional detection capabilities were required.

The suspicious files were stored locally for analysis.

My investigation workflow followed these stages:

1. Initial scanning using Loki
2. YARA rule analysis
3. Malware family identification
4. Threat intelligence enrichment
5. Detection validation
6. Detection engineering improvements

Phase 1: Initial Detection with Loki

The first step was to scan the suspicious files using Loki.

Loki is a lightweight IOC scanner that combines YARA rules, file indicators, and threat intelligence signatures to identify potentially malicious files.

After scanning the first file, Loki immediately reported:

• Suspicious Object Detected
• Web Shell Classification
• YARA Rule Match

The scan identified the file as:

webshell_metaslsoft

At this stage, the evidence strongly suggested that the file was malicious.

However, I wanted to understand why the file triggered detection rather than simply accepting the tool output.

Phase 2: Understanding the YARA Detection

The YARA match revealed that the file triggered a specific rule associated with known web shell behavior.

Reviewing the detection details showed:

• Rule Name: webshell_metaslsoft
• Matching String: Str1
• Classification: Web Shell

Further investigation revealed the malware family:

b374k 2.2

This was my first reminder that YARA is far more than a simple signature matching tool.

Instead of merely identifying malware, YARA provided visibility into exactly what pattern caused the detection.

This transparency is one reason YARA remains highly relevant within threat hunting, malware analysis, and incident response teams.

Phase 3: A Detection Failure Changes Everything

The second suspicious file produced an unexpected result.

Loki reported:

SYSTEM SEEMS TO BE CLEAN

Initially, this appeared reassuring.

However, given that both files originated from the same environment and appeared related, I decided to investigate further.

Manual inspection revealed:

b374k 3.2.3

This finding completely changed the investigation.

The scanner classified the file as benign, but evidence suggested otherwise.

At this point, the scenario shifted from malware detection into threat hunting.

Phase 4: Investigating the False Negative

The second file represented a classic false negative.

The malware was present, but existing signatures failed to identify it.

This taught an important lesson:

Automated detection tools are valuable, but they are not infallible.

A SOC analyst must always validate findings and investigate anomalies rather than blindly trusting tool output.

The newer variant contained modifications that prevented existing YARA signatures from matching.

As a result:

• Loki missed the threat
• Existing signatures failed
• Manual investigation became necessary

Phase 5: Creating New Detection Logic

To improve detection coverage, I generated a new YARA rule.

The generated rule contained:

• 20 unique strings
• File size restrictions
• Additional matching conditions

I validated the rule against the suspicious file.

The result:

Yay

The file was successfully detected.

After confirming functionality, I added the rule to Loki's signature repository and rescanned the environment.

The previously missed file was now correctly detected.

This was my first exposure to a simplified form of detection engineering.

Rather than waiting for vendors to release updates, I created detection content capable of identifying the threat myself.

Phase 6: Threat Intelligence Validation with Valhalla

Detection alone was not sufficient.

The next step was to validate findings using threat intelligence.

Using Valhalla and VirusTotal, I enriched the investigation by examining:

• File hashes
• Malware family information
• Existing YARA signatures
• Threat actor associations

Interestingly, not every antivirus engine identified the malware as malicious.

This reinforced another important lesson:

Detection counts alone should never determine whether a file is malicious.

Threat intelligence must be combined with analyst judgment.

By correlating multiple intelligence sources, confidence in the investigation increased significantly.

Key Lessons Learned

This investigation taught several valuable lessons:

Detection Is Evidence, Not Truth

A detection alert provides evidence.

It does not automatically provide certainty.

False Negatives Are Dangerous

The second file demonstrated how malware can evade existing signatures.

YARA Remains Highly Relevant

YARA enables analysts to create highly targeted detections and rapidly respond to emerging threats.

Threat Intelligence Improves Confidence

Threat intelligence enrichment transformed isolated file indicators into actionable intelligence.

Investigation Matters

The most valuable finding emerged only because manual investigation continued after the scanner reported the system as clean.

Analyst Report Summary

Incident Summary

Investigation identified multiple web shell samples associated with the b374k malware family on a web server.

Findings

• File 1 detected as b374k 2.2 web shell.
• File 2 identified as b374k 3.2.3 web shell.
• Existing signatures failed to detect the newer variant.
• Threat intelligence sources validated malicious classification.

Impact

Successful deployment of a web shell may allow:

• Remote command execution
• Unauthorized file access
• Credential theft
• Persistence within the environment

Recommendations

• Remove identified web shell artifacts.
• Update YARA detection signatures.
• Deploy updated Loki signatures.
• Review web server logs for attacker activity.
• Conduct additional environment-wide scanning.

Conclusion

This exercise began as a simple malware scan but evolved into a practical lesson in YARA, threat intelligence, and web shell detection.

The biggest takeaway was not learning how to run a tool. It was learning how to investigate beyond the tool.

The first file was detected immediately. The second file was missed completely. Only through continued investigation, threat intelligence enrichment, and custom YARA development was the full picture uncovered.

That experience closely mirrors real-world SOC operations, where the goal is not simply to receive alerts but to understand what they truly mean.

See what's next in my Threat and Vulnerability Management jounery: Vulnerability Management with Nessus and OpenVAS

Visit my everyday Cyber Playground