Forela carry out penetration testing of their internal networks utilising an internal team within their security department. The security team have notes from tests in addition to company critical credentials. It seems their host may have been compromised. Please verify how this occurred using the retrospective collection provided.
A Forela pen tester cloned a third-party enumeration repository from GitHub and ran its script as root against an internal target. The script hid its real purpose behind decoy comments and split, base64-encoded strings, and used them to fetch a password-protected zip from a file-sharing service. That dropped a large binary and a miner-style config into /tmp. Persistence was set with @reboot cron entries for both root and the pen tester’s own account, so the miner restarted on every boot. The repository’s commit history then showed the attacker swapping the download link and stripping the revealing comments within minutes, so the host evidence and the git history had to be read together to tell the whole story.
tar, then chmod -R u+rwx on the working copy because the archive preserves restrictive modes.bash_history → read with grep/tmp listing: used to date and size the dropped filesgit log -pGotcha: Five of the eight questions ask about the script’s contents and the repository’s commit history. Neither is inside the collection, so the repository named in the shell history has to be examined directly.
Unpack the collection and read the pen tester’s .bash_history. A git clone of a GitHub repository is followed straight away by sudo bash on a script from that repo, pointed at an internal IP. The file timeline agrees: a directory named after that IP, a hidden zip and an unknown binary all appear in /tmp immediately after the run.
grep -nE 'git clone|sudo bash' home/johnspire/.bash_historyFrom Q1 the script is enum.sh from the cloned repo, run with sudo bash. The collection only holds its effects, so read the script itself from the repository. Its enumeration functions are ordinary; one function downloads and runs a payload, and its name is what the question wants.
grep -n 'function\|()' enum.shInside do_wget_and_run the password is not stored in the clear. It is split across two variables, part1 and part2, each base64-encoded. Concatenate them and decode the result. This is the hidden /tmp/.hidden_*.zip from the timeline being unpacked.
echo 'c3VwZXI=aGFja2Vy' | base64 -dGotcha: Decoding
part1andpart2separately gives two fragments. Join the encoded strings first, then decode once.
The download URL is obfuscated the same way: it is split into two variables, f1 and f2, inside the same function and only becomes a working link when the script joins them. Join the two pieces in order. Nothing in the host’s shell history shows the transfer, because the script made the request, not the user.
grep -nE 'f1=|f2=|FILE_URL' enum.shThe repo history shows the function first disguised with decoy comments, with the real ones removed in a later commit. Read the full patch history for the script and find the commit whose diff deletes the genuine comments from do_wget_and_run. Commit 7d203152, titled Update enum.sh, does this, and its AuthorDate is the answer. Use the author timestamp, which is UTC on this repo.
git log -p --date=iso -- enum.shSame history, one commit earlier. Commit 5d88bee8 (22:23:41, a few minutes before the comment cleanup) shows in its diff the FILE_URL as it stood before the attacker swapped it. The current script only shows the replacement, so the old link exists only in the git history.
git show 5d88bee8Tip: Any attacker repo named in evidence is worth
git log -p. Old commits keep the removed comments and earlier URLs that the final version hides.
The cron data from the collection holds an @reboot entry that launches the /tmp binary, present in both the root crontab and the pen tester’s own. A scheduled job that runs at boot is the Cron sub-technique of Scheduled Task/Job.
grep -r '@reboot' cron/ var/spool/cron/The binary named in the cron entry is an 8.3 MB file in /tmp, sitting next to a config.json. That config layout is a miner’s, so the binary’s purpose is to burn the host’s CPU for the attacker, which is Resource Hijacking. This one is reasoned from the binary and its config rather than read from a single artifact: the binary was not executed or unpacked.
ls -la tmp/ && sha1sum tmp/blob| Phase | Action |
|---|---|
| Initial Access | Pen tester clones a third-party enumeration repo from GitHub |
| Defense Evasion | Attacker disguises the payload function with decoy comments and base64-split strings, and later removes the real comments |
| Execution | Script run with sudo bash against an internal host |
| Execution | do_wget_and_run fetches a password-protected zip from a file-sharing link |
| Execution | A hidden zip, an 8.3 MB binary and a config file are dropped in /tmp |
| Persistence | @reboot cron entries added for root and the pen tester to relaunch the binary |
| Impact | Miner runs with root privileges on the host holding the team’s notes and credentials |
| Type | Value |
|---|---|
| Repository | hxxps[://]github[.]com/pttemplates/autoenum |
| URL (final) | hxxps[://]www[.]dropbox[.]com/scl/fi/uw8oxug0jydibnorjvyl2/blob.zip?rlkey=zmbys0idnbab9qnl45xhqn257&st=v22geon6&dl=1 |
| URL (earlier commit) | hxxps[://]www[.]dropbox[.]com/scl/fi/wu0lhwixtk2ap4nnbvv4a/blob.zip?rlkey=gmt8m9e7bd02obueh9q3voi5q&st=em7ud3pb&dl=1 |
| Zip password | superhacker |
| Script | enum.sh (function do_wget_and_run) |
| File | /tmp/blob (sha1 begins ea7c9729) |
| File | /tmp/config.json |
| File | /tmp/.hidden_*.zip |
| Cron | @reboot /tmp//blob (root and the pen tester’s crontab) |
| Technique | ID | Description |
|---|---|---|
| Command and Scripting Interpreter: Unix Shell | T1059.004 | Cloned script run with sudo bash |
| Obfuscated Files or Information | T1027 | Password and URL split into base64 and string fragments; decoy comments |
| Ingress Tool Transfer | T1105 | do_wget_and_run pulls the zip from a file-sharing service |
| Scheduled Task/Job: Cron | T1053.003 | @reboot entries relaunching the dropped binary |
| Resource Hijacking | T1496 | Miner binary with its config in /tmp |
Unreviewed third-party scripts should never run as root. The compromise came from sudo bash on a freshly cloned repo. Pin or vendor the tooling the pen test team uses, review it before first use, and run it as an unprivileged user in a disposable VM.
Split, encoded strings in a shell script are a review red flag. The zip password and the download URL were each broken into fragments and base64-encoded so a quick read or a grep for http found nothing. Flag any script that reassembles strings at runtime, and a wget or curl whose target is built from variables.
Check the commit log, not just the latest version. The attacker swapped the download link and stripped the revealing comments within minutes of each other. Reviewing only the head commit misses the earlier link and the original intent, so audit git log -p before trusting a tool.
Cron entries pointing into /tmp are an easy detection. Two @reboot lines launching a binary from a world-writable directory are rarely legitimate. A scheduled FIM or auditd rule on crontab changes, plus an alert on any cron command path under /tmp, would have flagged this at creation.
A pen tester’s workstation is a crown-jewel host. It held test notes and company credentials, yet was treated like any other machine that could pull code from the internet. Restrict outbound access from these hosts and keep the credential store off them.
A cloned enumeration script gave an attacker root on the machine that held the security team’s notes and credentials, and two
@rebootcron lines kept a miner alive across reboots. The host evidence shows what ran and how it persisted, but the obfuscated download stage and the attacker’s edits live only in the repository’s history, which is why it has to be read alongside the triage data.