Changed ImunifyAV from asynchronous queue mode to synchronous scan mode
to ensure scanners run sequentially and each completes before the next starts.
Problem:
- Used "malware on-demand queue put" which queues asynchronously
- Scanner immediately moved to next scanner without waiting
- Broke sequential scanning requirement
- Output showed "scans queued" but scan was still running
Solution:
- Changed to "malware on-demand start --path" (synchronous)
- Blocks until scan completes
- Shows progress: "→ Scanning: /path"
- Extracts infected count from malicious list
- Now properly sequential: ImunifyAV → ClamAV → Maldet → RKHunter
Result:
- All 4 scanners now run completely sequentially
- Each scanner waits for previous to finish
- Proper "scan complete" reporting for ImunifyAV
- Infected file counts tracked correctly
Ensures scan integrity and proper resource management.
Changed rkhunter from permanent installation to temporary session-based use,
aligning with toolkit's "Download, Run, Fix, Delete" philosophy.
Behavior:
- Standalone scanner checks if rkhunter is installed
- If NOT found: Auto-installs temporarily with EPEL
- Updates definitions and initializes baseline
- Runs the scan
- Auto-removes rkhunter at end of scan session
- Tracks installation with RKHUNTER_TEMP_INSTALLED flag
Benefits:
- No permanent footprint on server
- Automatic cleanup after use
- Still available in "Install All Scanners" for users who want it permanent
- Standalone scans are truly self-contained and temporary
Implementation:
- Added RKHUNTER_TEMP_INSTALLED tracking variable
- Auto-install logic before scanner detection
- Silent installation (yum &>/dev/null)
- Auto-removal after scan completes
- Logged in session.log for transparency
RKHunter is system-level (checks binaries/kernel) not file-level,
so it doesn't need to persist - perfect candidate for temp install.
Integrated rkhunter for comprehensive rootkit/backdoor/exploit detection
alongside existing ImunifyAV, ClamAV, and Maldet scanners.
Features:
- Detection: is_rkhunter_installed() checks for installation
- Installation: Auto-enables EPEL, installs rkhunter, updates definitions
- Baseline: Initializes property database with --propupd
- Scanning: Uses --check --skip-keypress --report-warnings-only
- Reporting: Tracks warnings and detected rootkits
- Documentation: Added to installation guide with full instructions
Integration points:
- detect_scanners(): Added rkhunter to available scanners list
- show_scanner_installation_guide(): Added installation instructions
- install_all_scanners(): Added [4/4] installation with EPEL setup
- Standalone scanner: Added rkhunter detection and scan case
Scan behavior:
- Updates rootkit definitions before each scan
- Runs comprehensive system checks (no user interaction)
- Reports warnings count in summary
- Extracts found rootkits to infected_list
- Runs sequentially with other scanners
Research: Based on 2024-2025 best practices from rkhunter documentation
- Version: 1.4.6 (current stable)
- Free and open source
- Available in EPEL repository
The docroot extraction from /etc/userdatadomains was completely broken,
causing scans to target invalid paths like "main" instead of actual
document roots like /home/user/public_html.
Problem:
- Used `cut -d= -f5` which treats EVERY = as delimiter
- File format uses == as delimiter: user==owner==main==domain==docroot==...
- This caused field 5 to be "main" instead of the docroot path
- Result: Scanners scanned zero files and completed in seconds
Solution:
- Use `awk -F'==' '{print $5}'` to properly parse == delimited fields
- Extract field after colon, then split by ==
- Added -d check to ensure docroot exists before adding
- Fixed both detect_control_panel() and get_user_docroots()
Impact:
- Malware scans now actually scan real document roots
- Full server scans will take appropriate time (not 10 seconds!)
- Users will see actual file counts and scan progress
- Added missing source for reference-db.sh library in malware-scanner.sh:15
- Created store_reference() and get_reference() functions in reference-db.sh
- Functions use REF|key|value format in .sysref database
- Fixes "store_reference: command not found" errors at lines 816-817
Changes:
- Show 'please wait' message for long installation
- Display installation progress from deployment script
- Clean up any existing deployment script first
- Show relevant output: Installing/Installed/Complete/Error
- Remove suppression of all output
This should make ImunifyAV installation more visible and debuggable.
Scanner Detection Improvements:
- Created dedicated detection functions for each scanner
- is_imunify_installed(): Checks command and /usr/bin location
- is_clamav_installed(): Checks command, cPanel path, and RPM
- is_maldet_installed(): Checks command and /usr/local/sbin
ClamAV Fixes:
- Now detects cPanel-installed ClamAV correctly
- Checks for cpanel-clamav RPM package
- Finds clamscan in /usr/local/cpanel/3rdparty/bin/
- Handles already-installed cPanel ClamAV gracefully
- Dynamically finds freshclam binary for updates
ImunifyAV Improvements:
- Better installation detection
- Finds binary dynamically for updates
- Handles various installation paths
Benefits:
- Scanners installed via cPanel are now detected
- No false "not installed" errors
- Better handling of non-standard install paths
- More robust binary finding for updates
User feedback addressed: Detection was failing for cPanel-installed
scanners that weren't in standard PATH locations.
Enhancements:
- All scanners now update signatures immediately after installation
- Signature updates are visible with progress messages
- Show relevant output from update commands
- Graceful fallback if update output parsing fails
Updates per scanner:
1. ClamAV:
- freshclam runs immediately post-install
- Shows "updated", "Downloaded", or "up-to-date" messages
- Confirms with green checkmark
2. Maldet:
- maldet -u runs immediately post-install
- Shows "update completed" or signature count
- Confirms with green checkmark
3. ImunifyAV:
- imunify-antivirus update runs immediately post-install
- Shows "updated", "Success", or "completed" messages
- Confirms with green checkmark
User feedback addressed: Signatures should update automatically
right after installation, not silently in background.
Architecture Changes:
- ALL scans now use standalone scanner (/opt deployment)
- Toolkit serves as monitor/manager, not executor
- Removed direct scanning from toolkit entirely
New Features:
- Bulk scanner installation (install all 3 at once)
- Scan status checker with live progress
- Session manager (delete individual or all completed scans)
- Enhanced menu structure with clear separation
Menu Organization:
1. Create New Scan (server/user/domain/custom) → generates standalone
2. Monitor & Manage (status/results/delete)
3. Configuration (install all/settings)
Removed Functions:
- scan_entire_server() - now via standalone
- scan_user_account() - now via standalone
- scan_domain() - now via standalone
- scan_custom_path() - now via standalone
- run_all_scanners() - embedded in standalone
- scan_imunify/clamav/maldet() - embedded in standalone
Benefits:
- Cleaner separation of concerns
- Consistent scan execution (all via standalone)
- Better resource management
- Toolkit can be deleted during scan
- Centralized scan monitoring
Enhancements:
- Auto-install screen when not available (yum/apt-get support)
- Nohup fallback option if user prefers no screen installation
- Enhanced view_scan_results to show standalone scanner sessions
- Display session status (running/completed) for standalone scans
- Show summary, infected files, and logs for each session
- Track PIDs for nohup-launched scans
Screen handling:
- Option 1: Auto-install screen (recommended)
- Option 2: Use nohup fallback (no dependencies)
- Option 3: Cancel operation
Results viewer improvements:
- Separate toolkit and standalone scan results
- List all /opt/malware-* sessions with status
- Show summary, infected files, and recent logs
- Provide commands to monitor ongoing scans
This ensures the standalone scanner works even on minimal
systems without screen pre-installed.
Features:
- Standalone scanner generator that runs independently in /opt
- Launch in screen session for background execution
- Self-contained script with no toolkit dependencies
- Self-cleanup with user confirmation after completion
- Scanner installation guide for ImunifyAV, ClamAV, and Maldet
- Menu option 5: Launch standalone scanner
- Complete scan scope selection (server/user/domain/custom path)
Implementation:
- Added show_scanner_installation_guide() function
- Added launch_standalone_scanner_menu() function
- Enhanced generate_standalone_scanner() with screen integration
- Integrated with main malware scanner menu
Use case: Long-running scans can be launched independently,
allowing toolkit deletion while scans continue in background.
New Features:
- 'All Available Scanners' option in all scan modes (server/user/domain/custom)
- Runs ImunifyAV, ClamAV, and Maldet sequentially with progress tracking
- Creates consolidated multi-scanner session reports
- Shows [1/3], [2/3], [3/3] progress indicators
- 3-second wait between scanners to prevent system overload
- Session reports saved to logs/malware-scans/multiscan_*.txt
- Stores session IDs in reference database for cross-module access
- New 'Compare scanner results' option (menu option 6)
- View consolidated reports from multiple scanners
Workflow:
1. Select any scan scope (server/user/domain/path)
2. Choose 'All Available Scanners' option
3. All installed scanners run automatically one after another
4. Single consolidated report with all results
5. Use option 6 to compare/view latest multi-scanner session
Much more automated - no need to run each scanner separately!
Malware scanning is now more prominent:
- Moved from Web Application Analysis submenu to main Security Analysis menu
- Now option 1 (🦠 Malware Scanner) in Analysis & Troubleshooting
- Direct path: Security → Analysis → Malware Scanner (2→1→1)
- Removed from Web Application submenu to avoid duplication
- Renumbered all security analysis options accordingly
Much easier to find and access the malware scanner now.
New workflow:
1. User runs: source run.sh (instead of bash launcher.sh)
2. Launcher runs normally
3. On exit with cleanup=yes, launcher sets flag file
4. Wrapper detects flag and does ALL cleanup automatically:
- Cleans ~/.bash_history file
- Clears current shell's in-memory history
- Removes toolkit directory
- No manual commands needed
The key: wrapper is SOURCED so it runs in parent shell and can modify history.
User experience: answer "yes" and cleanup happens instantly, automatically.
Changes:
- Cleans ~/.bash_history file immediately when user selects yes
- Verifies curl command is gone from file before continuing
- Removes logs, temp files, toolkit directory automatically
- Shows verification: "✓ Verified: No curl download commands in history file"
- User just needs to run: history -c, unset HISTFILE, exit
No more asking user to source scripts. Just do the cleanup and verify.
Exit menu now tells user to SOURCE the trace eraser instead of running it as subprocess:
- Single command: TRACE_ERASER_AUTO=yes source tools/erase-toolkit-traces.sh
- Sourcing runs it in current shell, allowing it to modify that shell's history
- No more separate helper scripts or multiple steps
- Single source of truth for all cleanup logic
This fixes the parent shell history issue - by sourcing instead of running as subprocess, the trace eraser can actually modify the shell's history where the curl command was executed.
Exit menu now:
- Calls trace eraser in TRACE_ERASER_AUTO=yes mode (no prompts, removes everything)
- Creates minimal helper script only for parent shell history cleanup
- Single source of truth: tools/erase-toolkit-traces.sh
Removed duplicate cleanup logic from launcher exit handler.
The fundamental issue: launcher.sh runs in a subprocess, so it cannot modify the parent shell's history where the curl command was executed.
Solution: Create a temporary cleanup script that the parent shell must source after launcher exits. This allows the history cleaning to run in the correct shell context.
User workflow:
1. Run launcher.sh and select exit with cleanup
2. Source the generated /tmp/.cleanup_history_$$.sh script
3. History is cleaned in the parent shell
4. Exit and restart shell to verify
The cleanup script removes toolkit traces from ~/.bash_history and disables history recording for the current session.
Simplified to match the exact logic from erase-toolkit-traces.sh:
- Use grep -Ev with pattern matching
- Clean file, clear history, reload, unset HISTFILE
- Then run trace eraser subprocess for logs/files/directory
The key fix is running this in the current shell instead of subprocess.
The trace eraser was running as a subprocess, so history cleaning only affected the subprocess. The parent shell would still write its dirty history back to the file on exit.
Now the exit handler cleans history directly in the current shell before calling trace eraser:
- Cleans ~/.bash_history file with grep -Ev
- Runs history -c to clear in-memory history
- Reloads cleaned history with history -r
- Unsets HISTFILE to prevent re-writing on exit
- Then runs trace eraser subprocess for logs/files/directory cleanup
This ensures curl commands and all toolkit traces are actually removed from bash history.
Changes:
- Single question on exit: 'Clean history and remove traces?'
- If yes: runs full trace eraser automatically
- Auto mode skips all prompts, removes everything
- TRACE_ERASER_AUTO=yes flag for non-interactive mode
User experience:
- Exit (0)
- One question
- If yes: everything cleaned and removed automatically
- No multiple prompts
Changes:
- Prompt user to clean history when selecting Exit (0)
- Runs trace eraser if user answers 'yes'
- Shows clear message about what will be cleaned
User experience:
- Exit from main menu
- Asked: 'Clean history? (yes/no)'
- If yes: runs full trace eraser
- Then exits normally
Changes:
- Replace leading space with HISTFILE=/dev/null prefix
- More reliable - works on all systems
- Doesn't depend on HISTCONTROL settings
Command now prevents history recording universally
Changes:
- Remove comment line inside code block
- Keep just the clean curl command
- Shorter tip below code block
Now easy to copy the command without extra lines
Changes:
- Add leading space before curl command in README
- Add privacy tip explaining HISTCONTROL=ignorespace
- Updated comment to indicate privacy feature
Command now includes space to prevent history recording:
curl -sL https://git.mull.lol/.../tar.gz | tar xz && ...
Changes:
- Add tip about using leading space to prevent history recording
- Shows example with space before curl command
- Explains HISTCONTROL=ignorespace behavior
Best Practice:
curl -sL https://git.mull.lol/.../tar.gz | tar xz
↑ Leading space prevents command from being saved to history
Works on most systems where HISTCONTROL includes ignorespace
Changes:
- Remove complex history -d loop (unreliable)
- Clean file directly with grep -Ev only
- Clear current session with history -c
- Unset HISTFILE to prevent session from writing on exit
- Disable histappend for current session
Issue:
- Complex history manipulation was unreliable
- Current session kept re-adding commands on exit
- history -w then grep -Ev was conflicting
Solution:
- Just clean the file, period
- Unset HISTFILE so current session won't write anything
- Tell user to exit immediately and start fresh shell
Tested:
✓ File cleaned with grep -Ev
✓ HISTFILE unset prevents writing on exit
Changes:
- Add history -c && history -r after cleaning file
- Reloads cleaned history into current session
- Prevents bash from appending dirty history on shell exit
Issue:
- Trace eraser cleaned file but current session kept dirty history
- On shell exit, bash appended current session to file
- All curl commands were re-added to ~/.bash_history
Solution:
- After cleaning file, clear and reload current session history
- Current session now has only cleaned history
- On exit, only clean commands are appended
Tested:
✓ File cleaned with grep -Ev
✓ Current session reloaded from cleaned file
Changes:
- Move bash history cleaning BEFORE directory removal prompt
- Ensures history is always cleaned regardless of directory choice
- Remove exit 0 that was skipping history cleaning
Issue:
- When user answered "yes" to remove directory, script exited immediately
- History cleaning code never executed (was after exit 0)
- User's curl commands remained in ~/.bash_history
Solution:
- Restructure: clean history first, then ask about directory
- History cleaning always runs now
Tested:
✓ History cleaning happens before directory prompt
✓ Works whether user keeps or removes directory
Changes:
- Clean ~/.bash_history file directly after in-memory cleaning
- Handles commands from other terminal sessions
- Ensures complete cleanup even if history not yet written
Issue:
- history -d only cleans current session's in-memory history
- Commands from other sessions remain in ~/.bash_history file
- User's curl command persisted because it was from different session
Solution:
- After history -w, also grep -Ev on the history file
- Removes toolkit commands regardless of which session added them
Tested:
✓ Pattern matches user's curl command format
✓ Extracts correct entry numbers
Changes:
- Remove all 'history' command entries after toolkit cleanup
- Prevents showing investigation/debugging commands
- Uses same history -d approach for consistency
Removes:
- history
- history | grep curl
- cat .bash_history
- Any other history command variants
Tested:
✓ Removed 3 history command entries from test
✓ Only clean commands remain in history
Changes:
- Replace complex awk/grep file manipulation with history -d
- Use in-memory history deletion instead of file parsing
- Delete entries in reverse order to maintain numbering
- Write cleaned history back to file with history -w
Benefits:
- Much simpler and more reliable
- Works with any HISTTIMEFORMAT configuration
- Native bash command handling (no awk complexity)
- Automatically handles timestamps correctly
- User-suggested improvement
Tested:
✓ Deletes 3 toolkit entries from 7-line test history
✓ Preserves normal commands
✓ Timestamps handled automatically by history -d
Changes:
- Replace grep with awk to handle timestamp lines
- Remove matching commands AND their preceding timestamp lines
- Properly handle history format: #timestamp followed by command
Issue:
- Systems with HISTTIMEFORMAT set store timestamps as #<unix_time>
- Simple grep only removed command lines, left orphaned timestamps
- User's history showed toolkit commands still present (lines 990-1030)
Solution:
- awk script that tracks timestamp lines
- Only prints timestamp if following command is kept
- Removes both timestamp and command together atomically
Tested:
✓ Removes 16 lines (8 commands + 8 timestamps) from 32-line test
✓ Preserves normal commands with their timestamps
✓ No toolkit patterns found after cleaning
Changes:
- Replace chained grep -v with single grep -Ev for efficiency
- Fix critical bug: history -w was overwriting cleaned file
- Use history -r instead of history -w to reload cleaned history
- Single-pass filtering instead of 5 separate grep processes
- Better user messaging about other terminal sessions
Technical improvements:
- Escaped regex metacharacters in pattern (git\.mull\.lol)
- Use 3988207 for unique temp file names
- More efficient: 1 process vs 5 processes
Tested:
✓ Removes all toolkit commands regardless of position
✓ Preserves normal commands
✓ No temp file errors
✓ History properly reloaded into memory
✓ 7 toolkit entries removed from 20-line test history
Changes:
- Calculate lines removed before deleting temp files
- Add error handling to line count calculations
- Prevent 'No such file or directory' error on line 163
Tested:
✓ Pattern-based removal works correctly
✓ Removes toolkit entries regardless of position
✓ No temp file access errors
Added 'set +o history' to prevent the trace eraser commands from being re-added to history.
Changes:
• Disable history recording before cleaning (set +o history)
• Clear in-memory history with history -c
• Write empty history with history -w
• Added note to run 'exec bash' for clean shell
• Prevents script commands from being saved
This ensures the last 10 entries are properly removed and the cleanup commands themselves don't get recorded.
Reduced from 50 to 10 entries for more targeted cleanup.
Changes:
• Only removes last 10 bash history entries
• More conservative approach
• Still covers toolkit download and usage
• Less impact on normal command history
Tested and confirmed working.
Bash history cleaning was happening too early, causing script commands to be re-added to history.
Changes:
• Moved history cleaning to the very end of the script
• History is now cleaned after all other operations complete
• Prevents script commands from being re-added to history
• Clear in-memory history as final action
Now properly removes the last 50 bash history entries including all toolkit-related commands.
User bash histories are now completely skipped. The script only cleans root's bash history.
Changes:
• Removed user history detection and cleaning
• Removed prompt for user history cleaning
• Only root bash history is cleaned (last 50 entries)
• Faster execution, no prompts for user accounts
IMPORTANT: All future commits should NOT include:
- Claude Code attribution
- Any AI-related signatures
Commits should be clean and professional without AI attribution.
User bash history cleaning is now optional with a prompt, since most users only work as root.
Changes:
• Added user count detection
• Prompts: "Clean user bash histories too? (y/n) [n]"
• Default is "no" (skip user histories)
• If no users exist, automatically skips
• Only cleans root history by default (faster, covers 99% of use cases)
This makes the script faster and more sensible for typical usage where only root is used to run the toolkit.
cschantz