LFIC (LFI Commander)

LFIC is the platform's LFI Commander. When a target has an LFI vulnerability, LFIC uses it to retrieve files from the server, then presents them in a browsable file tree you can read and download.

LFIC is configured and run per host. You can start from Tools → LFIC → New LFIC Scan without leaving the tool page, or open a host and choose the LFIC tab (see Host detail). The setup wizard (Edit Config on the host tab, or the setup step inside New LFIC Scan) is where the LFIC request template lives — injection path, encoding, wrappers, and the rest of the request setup.

From the project sidebar, Tools → LFIC lands on hosts this tool has already scanned (Hosts / Scans toggle). New LFIC Scan opens a modal on that page: pick or add a host, run setup if the host has no injection point yet, then launch. It does not navigate to the host tab. See Scans → New LFIC Scan.

Host Target Config edits only Host / Port / SSL — not the LFIC template. See Target Config tab.

Host Scan Defaults can pre-fill shared options (User-Agent, Secret Detection, etc.) for new LFIC scans — see Scan Defaults tab.

Overview of the workflow

1. Configure the target's LFI using the setup wizard — you describe the vulnerable request and confirm LFIC can read a known file.
2. Run a scan by picking file modules and/or filesets to retrieve.
3. Browse and download the retrieved files in the explorer.

Setup wizard

The first time you configure a host (host LFIC tab, or New LFIC Scan for a host that needs setup), the setup wizard walks through five steps. To change a template that is already saved, use Edit Config on the host LFIC tab.

1. Request

Describe the vulnerable request:

• Label, Hostname, Port, TLS, and Follow Redirects.

• A Raw HTTP Request containing the LFI. Mark where the file path goes with the @INJECT@ placeholder (click the placeholder chip to copy it). Include any path traversal needed to reach the drive root, for example:

  GET /vuln.php?file=../../../@INJECT@ HTTP/1.1
  Host: target.example.com
  Cookie: session=abc123

Pasting a raw request auto-fills the hostname/port/TLS where possible. Every @INJECT@ in the field is highlighted, so you can see at a glance where the path lands. Validation errors — a missing @INJECT@, for one — clear as soon as you edit the request or the hostname, so the message in front of you is never left over from an earlier attempt.

2. Configuration

Choose how the injected path is encoded and how probe requests are sent:

• URL Encoding — off, Minimal, or Full.
• Base64 Encoding — base64-encode the file path.
  • Strip padding — appears once Base64 Encoding is on. Drops the trailing =. Most decoders accept unpadded base64, and some targets and WAFs reject or mangle the =.
• Replace / with — tick the box and type a replacement (up to 100 characters) for every / in the injected path, for a sink or WAF that blocks a literal slash. You supply the exact replacement your sink needs — chr(47) for a PHP sink, %2f, \, anything.
  • surround words with — an optional second field beside it. When set, each path segment (the runs between /) is wrapped with this string on both sides and all tokens are joined with ., building a concatenation expression. With Replace / with = chr(47) and surround words with = ", /etc/hosts becomes chr(47)."etc".chr(47)."hosts" — the shape a PHP file_get_contents(…) sink needs. A live /etc/hosts → … preview shows the result as you type.
  • The result is an expression in the sink's own language, so it goes out verbatim — URL and Base64 encoding are skipped while this is set, because encoding would corrupt it.
• Wrap as php://filter — tick the box to send the path as php://filter/<chain>/resource=<path> (chain defaults to convert.base64-encode; type another like read=string.rot13 in the field). A PHP file sink then returns the file through the filter — its headline use is reading a .php file's source without executing it, which a plain path into an include()/require() sink cannot do. With the default base64 chain, also tick Base64-decode the result. A reversible chain (string.rot13) is undone for you on the extracted value, so matching — and the file you read in the viewer — is plaintext. Any URL/Base64 path encoding still applies after the wrap (for a sink that base64_decodes the path). Mutually exclusive with Replace / with.
• Base64-decode the result before matching — for targets that return the file base64-encoded, commonly in a response header (X-PT: …) rather than the body. The decode runs on the extracted value, after your wrapper or regex captures it, so it handles both shapes: a header leak your wrapper captures, and a body that is itself base64 (php://filter). With no extraction configured the whole body is the capture, so a pure-base64 body still decodes. The raw response is kept as evidence either way.
  • The decode is tolerant and layered: line-wrapped base64 (which php://filter produces), unpadded base64, and a blob truncated by Max File Size all decode, and up to three nested base64 layers are peeled — so a convert.base64-encode chain on a sink that also base64-encodes its output still lands on plaintext.
  • A decode whose result is mostly non-text is rejected and the raw value is kept instead. Without that, a base64-looking run in an error page's inlined CSS decoded to binary noise and was stored as the file's contents.
• Proxy — optional, used for probe testing (an enforced project proxy is shown and used automatically).
• Headers — extra headers applied to all requests including probes. If the project has headers configured, a Set Project Headers button copies them in; enforced project headers are shown read-only.

File paths containing a space — Library/Application Support/…, C:\Program Files\… — work regardless of the encoding settings; the bytes that would break the request line are escaped for you, and % is left alone so a null-byte poison such as /etc/passwd%00.php still goes out as written.

3. Probe

LFIC sends a test request for /etc/hosts and shows the response. Bare IPv6 targets use the same two host forms as IPv6 targets. If the file's contents are detected, the UI shows “/etc/hosts content detected — LFI confirmed.” If not, adjust the request and Try Again, or Continue Anyway.

With Base64-decode the result on, a Base64-decoded leak pane appears below the body whenever a plausible base64 run is found — in the body or in any response header — and the /etc/hosts check runs against the decoded text too. So a target that answers with X-PT: cm9vdDp4OjA6… still confirms here, with the file readable in that pane. No pane means nothing decodable was found; the raw body above is unchanged either way.

The probe is new work: it is refused without a valid license.

4. Extract

Tell LFIC how to pull the file contents out of each response. Select the leaked file content in the probe response — in the headers or the body — and LFIC captures the text immediately around it as Wrapper start / Wrapper end markers, which you can edit. A Live Preview shows exactly what will be extracted.

Matching runs over the response headers and body together, rendered as Name: value lines, then a blank line, then the body. So a leak in a header is extractable: select the value after X-PT: and the wrapper fills in with that header name as the start marker.

A start marker with no end marker captures to the end of that line, which is what a header leak wants. Selecting a value that runs to the end of its line leaves the end marker empty on purpose.

An end marker with no start marker captures from the start of the response up to the first end marker — use it when the leaked file sits at the top and you only need to cut the page markup that follows it.

You can also expand Advanced to write a free-form extraction regex, or Skip this step.

Wrappers match the response as shown — decoding happens after

Write markers against the text in front of you, including base64 you cannot read. With Base64-decode the result on, LFIC decodes what the wrapper captured, so the wrapper targets the encoded value and the decode turns it into file content.

An extraction that matches nothing discards the result

Once a wrapper or regex is configured, a response it does not match is treated as "file not found" and the path is not retained — it never reaches the file tree. This is deliberate: for a header leak, "not found" is the absence of the header, which a negative-match string cannot express. Scans with no extraction configured stay best-effort instead, where the status code and Negative Match String are the only suppressors.

5. Not Found

LFIC probes a random, non-existent path to learn what "file not found" looks like on this target. It uses either the status code or a Negative Match String (text that means "not found") to skip files that don't exist, keeping results clean. Then click Complete Setup.

Run a scan

From Tools → LFIC, click New LFIC Scan, choose a configured host (or add one and complete setup), pick modules/filesets, then Start LFIC Scan. That creates one scan and stays on the tool page.

From the host LFIC tab, with the target already configured, click Run Scan, choose what to retrieve, then Launch.

The launch form is split into three tabs rather than one long scroll. Launch and Cancel sit below the tabs at all times, and switching tabs keeps everything you have already filled in. If you press Launch with nothing selected, the form points you back to Scope.

Tab	What it holds
Scope	What to probe: Modules, Filesets, and the retrieval options below
Connection & Limits	Proxy, Concurrency, RPS, Delay, host limits, retry — see Settings → Throttle
Identity & Headers	The shared cross-tool options: User-Agent, Virtual Host, Root Path, Additional Headers — see Scan options

Modules and filesets

A scan is built from two kinds of source, and you can combine them:

• Modules — smart, purpose-built scan types. Each one seeds a curated set of file paths, and many also analyze what comes back to record host info or to generate follow-up requests automatically. See Scan types.
• Filesets — static lists of file paths to try, shown by their description with a file count. Use these to pull a known list of files without any extra analysis. See Filesets.

Above the fileset list:

• Everything / Linux recon / Web app / High value — scope presets. One click sets both the filesets and the modules; hover a preset for exactly what it picks. PHP Shell and Proc Explore are never selected by a preset — the first is actively exploitative, the second is over a million requests — so you opt into those by hand.
• Select all / Clear — select every fileset, or none. Unlike the presets, these two leave your module selection alone.
• Upload fileset sits below the list: name, optional description, one path per line or a file, up to 128 MiB. An uploaded set is selected for you straight away.

The Filesets label carries a live estimate — (4 selected, 2,345 before deduplication). It is the sum of the selected sets' file counts, so a path that two sets share is counted twice, and module-generated paths are not in it at all. LFIC deduplicates paths when the scan is created, which is why selecting broadly is cheaper than the number suggests.

Retrieval options

Also on the Scope tab:

Field	What it does
Include Binary Executables	Probe executable binaries (/bin/ls, …) as well. Off by default — they are large and rarely worth reading. Data files that happen to be binary (SQLite databases, .deb archives, journals) are not covered by this flag and are always probed.
Secret Detection	On by default for LFIC. See below.
Max File Size (MB)	Per-file read cap, 1–100. Blank uses LFIC's own default of 5 MB — larger than the other tools' 2 MB, because LFIC routinely pulls whole config and log files whose interesting part is at the end. This is the only bound on a retrieval: extraction and matching no longer impose a smaller one, so raising it really does get you more file.
Extraction Regex	A regex applied to each response, overriding the target's configured extraction for this scan only. Invalid regexes are flagged before launch.
LFIC Request Headers	One header per line (Name: value), applied on top of the shared Additional Headers.

Secret Detection reads every file LFIC keeps and reports exposed credentials as informational findings — the point being that an LFI which reads .env or wp-config.php should say the file held credentials, not just that it was readable. Three things worth knowing:

• It inspects the extracted file content — after your wrapper, regex and any base64/rot13 decode — not the wrapper page the vulnerable script returned. A secret in the surrounding page markup is not reported as a secret in your file.
• Only retained files are inspected, so the thousands of misses in a large scan cost nothing.
• One secret found in several files is one finding, and binary extractions are skipped (a snippet of binary around a regex hit is not reviewable evidence).

See Scan options → Secret Detection.

Force IPv6 is on the LFIC options panel — same behavior as on Scan options: pin to the target's AAAA record; launch fails if none exists or if IPv6 egress is unavailable. See IPv6 targets.

Select at least one module or fileset, then Launch. An unknown module name is refused — the error lists every unrecognised name. A typo does not start a scan that silently skips that module.

The Scans list on this tab (collapsible, at the top) shows this host's LFIC scans with pause, resume, cancel, and delete controls; it refreshes automatically while a scan runs. A failed cancel, delete, or config change is reported on the tab — it does not look like success. LFIC scans also appear on Tools → LFIC and the project Scans page — clicking a row opens scan detail. Results tells you the file explorer lives on this LFIC tab; Host view (or Open the full LFIC view for this host) is the way here.

Filesets

Filesets are named lists of file paths. Each row in the picker shows the set's description and its path count; hover for the full text. Built-in sets are tagged Built-in on Global Settings → LFIC and cannot be removed. Upload adds a custom set, which appears in the picker alongside the built-ins and can be deleted from Global Settings when no longer needed.

The built-in sets:

Fileset	Covers
Linux: common conf and system files	The short, high-value Linux list — start here.
Linux: extended linux file list	Less common Linux paths.
Linux: log files	Log locations across distros (also the raw material for a poisoning chain).
Linux: web server conf files	Apache/Nginx/other web-server configuration.
Linux: database conf files	MySQL/PostgreSQL and friends.
Ubuntu 25.10: /etc	/etc as enumerated from a live host.
Debian 13 (trixie): /etc and /var	/etc configuration, plus /var state, cache and logs.
AlmaLinux 9: /etc and /var	Same split for the RHEL family.
Amazon Linux 2023: /etc and /var	Same split; instance-specific paths deliberately left out, since they do not generalise between EC2 instances.
FreeBSD 15.1: /etc and /var	/etc plus /usr/local/etc (the ports web stack lives there, not under /etc), and /var state, logs and the pkg database.
MacOS: /etc, /private/etc	macOS configuration.
Web root (relative)	Bare relative paths — see below.

The per-OS /var sets are curated, not raw dumps: compiled policy blobs, profile caches and package metadata that merely restates a cheaper file were cut, while log files, cloud-init state, package databases and install manifests were kept. Nothing useful for reading through an LFI was removed.

Select broadly

Overlapping paths are deduplicated when the scan is created, so running four distro sets against one unknown host does not cost four times the requests — see the before deduplication note on the estimate.

Web root (relative)

The webroot_relative set ships bare, relative paths — no leading /, no traversal: web-server control files, language entry points, framework and app configs, VCS and dev leftovers, logs reachable from the application directory (for a poisoning → RCE chain), and SQLite databases and SQL dumps left in place.

Use it when the injection resolves against the application's own directory rather than the filesystem root, where the absolute /etc/… lists would miss app configs sitting beside the vulnerable script.

A relative hit does not tell you where the file was

Relative results are grouped under a single Relative folder, pinned to the top of the file tree, and are deliberately not shown with a leading /. The directory they were read from is unknown — it is whatever the vulnerable include() resolved against, often the including script's directory, but that is not guaranteed and it is not known to be the web root. The folder's tooltip says so. Being a synthetic group, it offers no folder-zip download; real subfolders inside it do.

Scan types (modules)

Module names appear in Title Case in the UI (for example PHP Shell for php_shell), with the same one-line description as below.

Module	What it does
proc_explore	Enumerate /proc filesystem (includes /proc/self and /proc/{pid}). The UI appends a computed request floor — today over 1.1 million.
home_explore	Extract and enum home dirs of users in /etc/passwd.
web_server_explore	Parse Apache/Nginx confs to find web root, logs, and environment variables.
platform_profile	Detect operating system version info.
php_shell	Attempt PHP log poisoning to inject webshell.

proc_explore

Enumerates the /proc filesystem — both /proc/self/… and every /proc/<pid>/… from PID 0 up to 65535 — pulling process files such as cmdline, environ, cwd, exe, maps, mem, status, and more. This is how you recover running command lines and process environment variables (which frequently contain secrets, tokens, and DB credentials) through an LFI.

Large and noisy

Because it walks every PID, proc_explore generates a very large number of requests — the module's own label in the picker states the floor, currently over 1.1 million. Expect it to be slow and to produce a lot of activity — tune Concurrency / RPS / Delay accordingly, and prefer running it on its own. No scope preset selects it.

home_explore

Fetches /etc/passwd, then:

• Records Total Users and Logins (real login accounts) as host info.
• Extracts each account's home directory and automatically queues follow-up requests for common sensitive files inside those homes (e.g. shell history and SSH material), so you don't have to guess paths per user.

web_server_explore

Fetches common Apache and Nginx configuration and environment files (apache2.conf, httpd.conf, RHEL conf.d/*.conf, Debian site configs, envvars, nginx.conf, …) and parses them to discover the webroot, log file paths, and server environment variables. The webroot is read from Apache's DocumentRootand Nginx's root directive, so webroot discovery works on Nginx targets too.

It guesses vhost config filenames, because a vhost config is usually named after the site rather than after the server. Each candidate name is tried in eight directory forms (Apache sites-enabled/sites-available and conf.d, Nginx conf.d and sites-{enabled,available} — the latter with no extension, as those directories conventionally use — plus a bare relative <name>.conf), and the names come from three places:

• The target host, then each parent domain: my.site.example.com also tries site.example.com, example.com and example. Hosts with no dot, and bare IPs, are skipped.
• Common environment words: prod, dev, qa, test, staging, uat, beta, demo.
• Up to three names derived from the host's recorded page title, since a vhost is as often named after the brand as after the domain. Stock server titles ("Welcome to nginx!", "Apache2 Ubuntu Default Page", "Index of", …) produce no names, and only a title already stored from an earlier scan is used — a host's very first scan has none.

It also seeds the RHEL/Alma/CentOS conf.d drop-ins (vhost.conf, ssl.conf, default.conf, …), cPanel userdata and source-build extra/httpd-vhosts.conf layouts.

Once a webroot is found, LFIC automatically queues probes for files under it — default index/entry pages (index.php, index.aspx, default.asp, …, which also positively confirm the webroot), plus app secrets and configs (.env and variants, wp-config.php, config.php, config/database.yml, config/master.key, application.properties, app/etc/env.php, .git/config, web.config, *.bak backups, and more). This is primarily reconnaissance that makes other attacks (especially php_shell) more reliable.

Every root found is kept, and every one of them is enumerated — not just the best guess. A server-level DocumentRoot really does serve whatever no vhost matches, so it cannot be ruled out from the config text, and an Nginx file with several server {} blocks has a root per block. You see both forms in the intel:

• Webroot — the single best candidate.
• Webroot Candidates — every root, best first, each annotated with the config file and vhost that produced it, for example /var/www/html/app/public (/etc/httpd/conf.d/example.com.conf, vhost example.com). It lands in the Other intel card because the list is long.

Best-first means: a vhost whose ServerName matches the target, then a drop-in config (conf.d, sites-*, conf-*), then any other vhost block, then a server-level root, with the deeper path breaking ties. Read the candidate list before concluding the webroot: on a real target the server-level root was /var/www/html while the application lived in /var/www/html/reds/public.

platform_profile

Fetches OS identification files — /etc/os-release, distro-specific *-release files, /etc/issue, and even macOS's SystemVersion.plist — to detect the operating system and version, recorded as host info.

Several of those files can answer, so the sources are ranked: /etc/os-release beats a distro release file, which beats /etc/issue. A better source always replaces a worse one, whichever response arrives first, so OS Version no longer depends on which probe happened to finish last. A banner with no version in it is rejected rather than stored — which also means a version-less /etc/issue such as Gentoo Linux contributes nothing, and those hosts are covered by /etc/os-release and the release files instead.

php_shell

Attempts PHP log poisoning: it finds a readable web-server log, poisons it with a nonce-protected PHP payload, re-reads the log through the LFI to execute it, and — if the payload runs — plants a command shell and files a critical finding.

It only poisons a log it has actually read: the log read has to come back as plaintext, non-empty, and not an HTML error or 404 page. Seeded log paths that don't exist on the target are therefore left alone, instead of generating poison-and-re-read noise (and 500s from the application) against files that were never there. Any log-shaped file in a log location qualifies — *.log, *.log.*, access_log, error_log — so apache_error.log, laravel.log, access_log.1 and vhost-named logs all count, not just the canonical names.

It poisons across several vectors in one pass so it works whether the readable log is an access log or an error log:

• the payload is sent in the User-Agent, Referer and X-Forwarded-For headers of a request to / (access logs record these), and
• in those same headers on requests to commonly denied paths (/.git/config, /.env, /.htaccess, /config.json, /secrets.json) — a server that denies them logs the request with its Referer into the error log.

The success marker is an md5() the payload computes, so it only matches if PHP actually executed (a log that merely recorded the request text can't fake it). The verify re-read is always allowed up to 64 MB regardless of Max File Size, so a large, busy log doesn't hide the freshly-appended payload at its end. The shell is planted with the same spread of vectors as the probe, so it lands in whichever log the probe proved readable; several vectors landing in one log still yields one finding and one shell.

The LFI sink must execute PHP (include/require). If it only reads the file (file_get_contents/readfile), the payload lands in the log but never runs — you get a medium "Poisonable, readable log (no code execution)" finding instead of a shell.

The critical shell finding carries how to use it: a sample_cmd_url, the fixed nonce, and the rule that every command request must include nonce=<value>&cmd=<command> (output returns inside <pre>…</pre>). The nonce is a secret — anyone with the URL and nonce can run commands, so don't share it, and remember the planted PHP persists in the log until it's rotated or cleared.

Requires web_server_explore

php_shell depends on web_server_explore (it needs the discovered log/webroot paths). Enable both, or the scan is rejected. This module is actively exploitative — only use it against targets you're authorized to test.

Browse retrieved files

Below the scans is the results explorer. It shows every file LFIC pulled off the target, laid out like a file manager. The area has three parts, top to bottom: an Intel strip, a files header, and a split pane with the file tree on the left and a content viewer on the right.

Intel strip

If LFIC's analysis (via modules like home_explore, web_server_explore, or platform_profile) learned anything about the host, a collapsible Intel Gathered strip appears at the top — a compact key/value table of designed facts such as OS version, webroot, log paths, user counts, server banner, and page title. An Other strip appears under it when there are additional host-info keys — including Webroot Candidates, which is kept there because it is a list rather than a single value and is rendered one root per line. Click a header to collapse or expand it. (Each strip is hidden when it has nothing to show.)

On the host Overview tab, the same data appears as Intel Gathered and Other cards. These facts live on the host, not the scan: deleting an LFIC scan removes that scan's retrieved files and findings, but keeps the gathered intel.

Files header

Above the tree:

• A Files label with a count of how many files are currently shown.
• A filter box — type 3 or more characters to narrow the tree to matching paths (matching folders auto-expand); clear it with the ✕.
• Expand all / collapse all buttons for the whole tree.

File tree

The left pane organizes retrieved files into a real directory tree reconstructed from their paths:

• Folders sort first, then files, alphabetically.
• Click a folder to expand/collapse it; the tree auto-expands on load and while filtering so results are visible without digging.
• Click a file to open it in the content viewer on the right.
• Hover a folder row to reveal a download icon that saves that folder (and everything under it) as a zip.
• On a file row, hover to reveal a file+ icon (Add to report). After a file is in the report, a green check replaces the icon; clicking the check removes it again. The same toggle appears in the content viewer header.
• Files read from a relative path are grouped under a synthetic Relative folder, pinned above the absolute roots — see Web root (relative) for why their directory is unknown.

The divider between the tree and the viewer is draggable, so you can widen either side.

Add files to the report

Use the file+ icon to attach retrieved file content to the project Report:

• File tree — hover a file row and click file+ (appears on the right).
• Content viewer — click file+ in the header next to the path (alongside download).

After adding, the icon becomes a green check (Added to report). Click the check to remove the file from the report again — an accidental add is undoable from here, without opening the Report page. The tree and viewer remember which paths are already reported when you reload the page.

Each host gets one Path Traversal report item; every file you add becomes a separate file evidence entry (path + snapshotted content) on that item. Open Report in the sidebar to review, remove individual evidence, export HTML/Markdown/JSON, or delete the whole item.

Adding a file to the report does not remove it from the explorer or delete the LFIC scan data.

Content viewer

Selecting a file shows its contents on the right:

• Header — the full file path and, when known, the HTTP status of the request that retrieved it, plus add to report (file+ / green check), a download button for the single file, and a trash button that deletes the file.
• Meta strip — the file size, when it was retrieved, and a binary badge (amber) for files that contain non-text bytes.
• Body — the file's contents. LFIC shows the extracted file content — the bytes captured by your extraction wrapper — rather than the raw HTTP response, so you see the clean file (any surrounding page markup the target wrapped around it is stripped out). Binary files show their real bytes.

Deleting a file

The trash button in the viewer header removes a retrieved file from the tree. It asks first, and then deletes every stored response for that path, across every scan of this host — not just the one you were looking at. That is deliberate: the tree shows one row per path, and a path LFIC fetched repeatedly is backed by many stored responses, so deleting a single one just brings the row back on reload sourced from an older scan.

The scans themselves are kept, as is anything already added to the Report — report evidence is a snapshot, so it survives the delete.

Downloading

• One file — the download button in the viewer header. Browsers that support it show a native Save As dialog; otherwise the file downloads directly. The suggested name is the file's base name.
• A folder — the download icon on any folder row saves a zip of that subtree (suggested name lfic-<folder>.zip).

Live updates and empty states

• While a scan is running, the explorer polls for new files automatically, so the tree grows as files come in.
• Before any files exist, the tree shows “No files retrieved yet — Run an LFIC scan to retrieve files.”
• If a filter matches nothing, the tree shows “No files match filter.”
• Deleting a scan also removes that scan's retrieved files from the tree.

Edit or remove the configuration

From the LFIC tab's toolbar:

• Edit Config reopens the setup wizard to change the request, encoding, extraction, or not-found settings.
• Delete Config removes the LFIC configuration for the host. Scan history and findings are kept.

Next steps

• Scan options — shared Options / Throttling on New LFIC Scan and the host tab
• Scans → New LFIC Scan — launch without leaving Tools → LFIC
• Review findings
• Build your report (including LFI Commander file evidence)
• Audit the activity log