CyberLock 9.0

  • Thread starter Thread starter danb
  • Start date Start date
  • Featured
VoodooShield
346 Replies 63,421 Views
I am having an issues with 9.15 where CyberLock 9.15 Smart Firewall in Recommended mode blocks WinRM/WS-Man connections to a Hyper-V host on TCP 5985. Test-NetConnection host -Port 5985 succeeds, but Test-WSMan host fails and curl reports Bad access. Disabling Smart Firewall immediately restores both Test-WSMan and Hyper-V Manager connectivity. Adding an outbound firewall rule for mmc.exe does not resolve it. Is there a Smart Firewall exclusion for WinRM/WS-Man or a trusted IP/port?
Hi, probably the best thing to do is the select Recommended mode, then adjust the firewall rules manually by clicking the little firewall icon to the right and then adjust them by clicking Advanced Settings. If that does not work for some reason, please let me know, thank you!
 
Hi, probably the best thing to do is the select Recommended mode, then adjust the firewall rules manually by clicking the little firewall icon to the right and then adjust them by clicking Advanced Settings. If that does not work for some reason, please let me know, thank you!
That worked like a charm....I was thinking Cyberlock did something else with the firewall stuff so it didn't even occur for me to look for rules from Cyberlock. We are good to go now....sorry to have troubled you.
 
That worked like a charm....I was thinking Cyberlock did something else with the firewall stuff so it didn't even occur for me to look for rules from Cyberlock. We are good to go now....sorry to have troubled you.
Sure, no problem at all. We could build out this feature to control Windows Firewall, but there are already great tools for that. Thank you!
 
Sure, no problem at all. We could build out this feature to control Windows Firewall, but there are already great tools for that. Thank you!

But your version of a Firewall Controller would be better. Look at what you did for Defender, with DefenderUI and DefenderUI Pro. I'd pay for a good firewall controller gui, sans Malwarebytes ugliness.
 
But your version of a Firewall Controller would be better. Look at what you did for Defender, with DefenderUI and DefenderUI Pro. I'd pay for a good firewall controller gui, sans Malwarebytes ugliness.
I appreciate that, thank you! Maybe some day... I am just not sure we would want it to be integrated into CyberLock, we want to keep CyberLock as lean and mean as possible. I could certainly see integrating it into DefenderUI though ;).
 
@danb - Ungoogled Chromium 154.0.8037.92-1.1

Total tokens: 0 (0 request / 0 response)

File path: c:\users\coco\appdata\local\chromium\application\chrome.exe
File hash: 906ce85fcc9ab0d3a0a0ef0539775c9e2d5c74a45d0b635cf95486415ff574b4
File size: 4.21 MB
File publisher: This file is a signable file type but has not been digitally signed.

Final Verdict: Not Safe with 92% confidence.

=== SiriusGPT analysis started at: 10/5/2026 6:50:16 PM ===

## Analysis Summary

This file presents a complex case requiring careful evaluation. The executable claims to be Chromium browser (chrome.exe) with matching version information and file paths consistent with a Chromium installation. However, critical security indicators are absent: the file is **completely unsigned** despite being a signable PE file, and it exhibits several anomalies including suspicious export functions and unusual string artifacts. The combination of legitimate-appearing metadata with missing security controls and atypical technical characteristics warrants significant concern.

## Detailed Analysis

### File Metadata and Version Information
The version information appears professionally crafted: "Chromium" as product name, "chrome.exe" as original filename, and copyright attribution to "The Chromium Authors" with 2026 date. The file path `c:\users\coco\appdata\local\chromium\application\chrome.exe` follows expected Chromium installation patterns. However, **the complete absence of digital signature** on a modern browser executable is highly anomalous—legitimate Chromium builds from Google or official sources are always signed. The `ValidSecurityDir: False` and `CertificateTableSize: 0` confirm no signature data exists.

### PE Structure and Entropy Analysis
The file contains 11 sections with generally reasonable entropy values (6.46, 5.62, 2.54, 6.08, etc.), though SectionEntropy3 at 2.54 suggests possible compressed or sparse data. The overlay entropy of 0.00 with zero overlay size indicates no appended data. Section flags appear standard with expected combinations of executable, readable, and writable permissions. The CLRRuntimeHeaderSize of 0 confirms this is native code, not .NET.

### Execution and Security Controls
ASLR and DEP are enabled (`OptionalHeaderDllCharacteristics: 0xC160`), indicating modern security-conscious compilation. The `asInvoker` execution level is standard for browsers. However, the `OptionalHeaderCheckSum: 0x00000000` is unusual—while not strictly required, most legitimate executables include a valid checksum.

### Import Analysis
The import table contains 254 functions with a diverse set of capabilities:

**Process and Memory Manipulation:**
- `CreateProcessW`, `CreateRemoteThread`, `OpenProcess`, `ReadProcessMemory`, `WriteProcessMemory`, `VirtualAllocEx`, `VirtualProtectEx` — these enable process injection and memory manipulation common in malware
- `CreateJobObjectW`, `SetInformationJobObject`, `TerminateJobObject` — job object management for process control

**Persistence and System Integration:**
- `CreateFileW`, `CreateDirectoryW`, `SetFileAttributesW`, `MoveFileW`, `ReplaceFileW` — file system operations for payload deployment
- `CreateNamedPipeW`, `ConnectNamedPipe`, `TransactNamedPipe` — inter-process communication mechanisms

**Evasion and Monitoring:**
- `IsDebuggerPresent`, `AddVectoredExceptionHandler`, `RemoveVectoredExceptionHandler` — anti-debugging and exception handling
- `NtQueryInformationProcess`, `NtQueryObject` — low-level system information queries

**Legitimate Browser Indicators:**
- Extensive locale and internationalization functions (`GetSystemDefaultLCID`, `GetUserDefaultLocaleName`, `EnumSystemLocalesEx`, etc.)
- Console and standard I/O handling
- Memory-mapped file operations for efficient resource loading

The `DangerousImportedLibrariesNormalized: 32.37 / 100` score reflects elevated but not extreme risk from imports. The presence of `dbghelp.dll` symbols and debugging functions suggests either development/debug build characteristics or intentional symbol manipulation.

### Export Analysis
Only **2 exports** are present:
- `GetHandleVerifier`
- `IsSandboxedProcess`

These are **highly suspicious** for a browser executable. Legitimate Chromium exports dozens to hundreds of functions for component integration. `IsSandboxedProcess` specifically relates to Chromium's sandbox security model, but the minimal export table suggests either:
1. A stripped/hollowed executable
2. A loader or wrapper around legitimate Chromium code
3. Malware masquerading as Chromium with minimal implementation

### String Analysis
Critical findings from meaningful strings:

**Rust Runtime Artifacts:**
- `RUST_BACKTRACE`, `panicked at`, `thread panicked while processing panic`, `memory allocation of bytes failed`
- These indicate Rust language compilation, which **Chromium does not use**—Chromium is primarily C++ with some Rust components only in very recent experimental builds, not in core browser executables

**Debug and Symbol References:**
- `dbghelp.dll`, `SymInitializeW`, `SymGetOptions`, `EnumerateLoadedModulesW64` — Windows debugging symbols
- `stack backtrace:` — Rust panic handling

**Internal Module References (suspicious):**
- `icon_reaM3`, `n_readerM3Y`, `print_baH3`, `_backendL3F`, `screen_aH3`, `xr_compoM3Y`, `pdf_convM3Y`, `proxy_reM3Y`, `resolverM3Y`
- These appear to be mangled or obfuscated internal module names, possibly indicating packed or modified code

**System Error Strings:**
- Standard POSIX-style error messages (`Operation not permitted`, `No such file or directory`, etc.) — unusual in Windows executables unless cross-platform compatibility layer present

## Speculative Software Assessment

This executable **does not appear to be legitimate Chromium**. The evidence suggests:

1. **Possible Malware Disguised as Chromium:** The matching metadata and paths with completely absent signature, minimal exports, and Rust compilation artifacts (incompatible with Chromium's actual codebase) strongly suggest impersonation.

2. **Potential Loader or Dropper:** The process manipulation imports, minimal exports, and module-like internal references could indicate a loader that deploys additional payloads while masquerading as a browser.

3. **Modified or Repackaged Binary:** The combination of legitimate-appearing version info with technical inconsistencies (Rust strings, no signature, suspicious exports) suggests modification of a legitimate binary or complete fabrication of metadata.

The file's characteristics align more closely with **sophisticated malware using brand impersonation** than with any legitimate software category. The technical sophistication (ASLR/DEP enabled, diverse API imports) combined with identity deception indicators creates a high-risk profile.

Malware type: Trojan.ChromiumImpersonator
Malware name: Dropper.RustLoader

Final verdict: Malicious with 92% confidence.
 
@danb - Ungoogled Chromium 154.0.8037.92-1.1
Thank you @oldschool. Yes, Sirius is instructed to be especially cautious with specific types of apps such as web apps, email clients and cybersecurity software, and expects them to be signed. If they are not signed, they can be easily compromised. So in this case, unfortunately the only real way Sirius is going to render a Safe verdict is if they start signing the files. And really, it is not a huge ask to have devs sign their work in this day and age.
 

Recently browsing

Members who viewed this thread in the last 5 minutes

Back
Top