@LLamaPie Well keep an eye on it, my concern is that there is a bug in php that allowed this to happen some how. Its in the http path and not the nfs path. Hopefully you will scan and or keep an eye on the cpu usage. When you detect a change surely review the apache logs both error and access as well as login logs to abnormal activity.

@adam1972 that is the debug shell, you can try the efsck command in debug mode then use the command ‘fog’ to step through the capture process

@mentaluproar sadly, due to the windows updates previously mentioned, which are actually fully enforced in the 2024-08 updates, a domain admin account is pretty much required to join the domain in an automated fashion. Microsoft gives some guidance on creating policies to allow a least privileged account but I haven’t been able to get that to work with fog. Granted, as long as your aren’t granting access to the fog gui to non privileged users, saving those creds in fog is safe and secured.

@lstassen is the driver the one you expect from the inf when it is installed via fog?
When manually installing are you running an install package?
Is there maybe a device settings tab where you need to tell the driver that the printer has the feature. You can use the fog printer settings file to save and deploy such settings. I haven’t used that feature in quite some time but I helped make it and this type of configuration was why it was added.

@Tom-Elliott The key is that its post the security update for FOG.

The question I have is:

1. How did that file/malware get onto the server
2. Why did it pick that specific path to hide in.
3. When was the server compromised. The date on the files in that directory may give us a clue.
4. Could it happen again? We don’t know because we don’t know how it was installed.

It almost seems intentional and deliberate to pick that specific path. I don’t think apache normally has write access to that path.

@OP is your fog server exposed directly to the internet?

@LLamaPie

/var/www/html/fog/management/.sys

Is not something that FOG creates. ref: https://github.com/FOGProject/fogproject/tree/stable/packages/web/management

.sys file / directory name means the directory is hidden unless you use the command ls -la /var/www/html/fog/management also .systmd is a hidden file made to represent systemd application.

I did find this article: https://sarperavci.com/ironshade-writeup-tryhackme/

So the question is how was this server compromised and if we don’t know it will probably happen again. What version of FOG did you have installed?

@shatchett0 So it is working now on the new install?

@MarkG OK let us know because there is some info that you can collect on these devices to help the developers validate the code.

@JamiesonCA092 ok it shows you have some debugging skills, so I’ll add a few new tools into your toolbox.

1. on the fos linux (target computer) when you schedule a task and tick the debug checkbox, when you pxe boot the target computer you will be dropped to the fos linux command prompt.
2. You can start the imaging process in single step mode by simply keying in fog at the command prompt.
3. The script will run until it hits a debugPause; command in the script. You can add that command in your custom script with echo statements to understand how your script is running. Pressing the enter key will cause the script to run again until the next debugPause command.
4. At the fos linux command prompt if you get the ip address of the fos linux (target computer) with ip a s and then give root a password with the passwd command (make it simple like hello, it will be reset at the next reboot). Once you have those 2 bits of into you can use putty or ssh from a second computer to the fos linux computer for debugging. Using this method you don’t have to sit in front of the target computer plus you can copy and paste using the putty/ssh session.
5. If you need to stop the fog script during hit ctrl-c to skip out of the script. At this point you can verify the environment, check the available variables, etc. When you are done looking around, then you can enter fog again to begin the imaging process once again. No reboot needed.
6. In the fog script the kernel parameters sent to fos linux are converted to bash script variables in the functs.sh script between lines 9 and 13 https://github.com/FOGProject/fos/blob/0efdd68f1783a06f3214607fc313db50747fbc43/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib/funcs.sh#L9

I’m pretty sure Wayne is right that the varialbles in the postinit script are local and will be erased when the script terminates. But I would test to be sure.

One last hack I can think of is that you can hack the fog.mount script https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.mount Put the logic to decide the target’s IP address into that script. The concept of dynamically patching the fog.mount script can be found in this tutorial (which addressing the fog.man.reg script) https://forums.fogproject.org/topic/14278/creating-custom-hostname-default-for-fog-man-reg but the concept and actions are the same.

@DBCountMan In the post init or post install scripts the $mac variable contains the mac address of the target computer

To get the ip address this script will work

myip=`ip route get 8.8.8.8 | awk 'NR==1 {print $NF}' | cut -d "." -f1-2`;

Getting the user id of who did it will be a bit harder since they never log into the web ui. The user ID and password they key in during the deploy image stays in ipxe and is not sent onto FOS Linux. I’d like to say that the username field can be trapped from iPXE and then pass that variable as a kernel parameter onto fos linux. Once that is done then the $username variable should exist in your fog scripts. Getting that info into the fog database is another challenge. In the post install script the /ntfs directory is mapped over to the fog servers /images/dev where you could append an echo statement into a text file.

Understand I’m taking in programming pseudo code. But I see an path here and it should work.