How to trace script injection/infection in php app

Question

This is about a PHP7.4 based shopping platform (opencart (v3.0)).

For testing purposes I had a dummy set up at site.com/xyz. The admin page of that was site.com/xyz/admin. The login and pw for the admin page was also admin. I know, but the purpose of the dummy was just to check if a certain extensions and other things worked. And the dummy gets uninstalled/reinstalled the whole time. This live test environment is completely sandboxed in a vm/container.

Now I noticed a bunch of strange scripts got injected in to the site. Whenever I opened it up and checked the sources in the browser in developer mode, there were a number (3-4) of different adware scripts. I didn't have time to check each of them individually because I needed to reinstall a fresh copy quickly.

But obviously it is a very vulnerable setup and will hopefully get infected again soon so I can replicate the scenario. I want to understand how to track/trace the infection.

I will be checking specific opencart files/logs (and if needed I will ask about it in the relevant forum).

On security.se, I want to ask which specific server logs should I check to track how this happened. Within the live test vm/container, the opencart app is accessed via Apache24. On the main host, nginx handles connections. The only vector, AFAIK, is the admin login page. So this is probably just automated scripts doing their magic?

Edit/add: The OS is FreeBSD.

Answer 1

You don't specify which host o.s. you're on, so I'll assume Linux.

In this revision, I now propose the use of the built in -printf function of find if your instal supports it, as it is vastly more efficient than spawning stat numerous times (possibly for every file).

I contrast the find -printf format against the stat format in this table, in the event that your version of find doesn't provide this function, and you still need to use stat:

#.fi..st.desc.#
# %i  %i inode number
# %s  %s size in bytes
#     %o "optimal I/O transfer size hint"
#     %b count blocks
#     %B block sz
# %A@ %X time of last access, seconds since Epoch
# %T@ %Y time of last data modification, seconds since Epoch
# %C@ %Z time of last status change, seconds since Epoch
# %m  %a permissions, octal
# %P  %n file-path and -name (without starting point)
# %f     file-name only
#     %N file deref'd name (symbolic link)
# %U    user-id
# %G    group-id

vprintf='%i+|%s+|+|+|+|%A@+|%T@+|%C@+|%m+|%P+|+|%U+|%G' && 
  find ~/your_ocart_dir -printf "$vprintf"'\n'

(Note that some metadata aren't available via find - I've left these columns in so outputs produced from each version align.) But wait, there's more! In this version, I chuck in a SHA2-384 hash of the file for extra-good measure, to be sure, to be sure. (This is limited to only files by -type f.)

find ~/your_ocart_dir -type f -printf "$vprintf"'\n' -exec sha384sum --binary "{}" \;   ## \; ensures alternate printf and sha384 lines

In my earlier version, I suggested you might stat the files and directories before the compromise occurs, to see if there are any differences afterwards?, however, this is less efficient than using the built-in features of find - I leave the stat option here for posterity, if for some reason, your version of find doesn't allow you to extract file metadata.

vstatformat='%i+|%s+|%o+|%b+|%B+|%Y+|%Z+|%X+|%#a+|%n+|%N' && 
  find ~/your_ocart_dir -exec stat --format="$vstatformat" {} \+

You would also grab the web server access logs, maybe in ~/access-logs/? Often times they come through via GET data in the query-string, which will show up in the access log.

Something else I've noticed is the attacks often pull stuff in via wget or curl, or a php function to that affect, write them where they can (ie. a writable upload directory), then call those files (you'll see this in the web server logs), then delete them. To prevent at least some of these being deleted, you could disable the unlink php function using disable_functions in php.ini. (This will let you come along later and find what code was run, however, often times the php code is obfuscated.)

Something else you can do, if you can instal things, use inotify (edit: or fswatch) to spot new files and copy them somewhere when they're first created.