This page describes the technologies and software used by LUCY. The information herein applies mostly to VM-based LUCY distributions (VMware Workstation, VMware ESXi, VirtualBox and Amazon) as LUCY installations on custom dedicated servers may have different configurations. The LUCY server contains different components. Those components are already installed when using our images (Vmware/AMI etc.) or are installed when using the Linux installer.
When you download and boot the VMware Image, all software components are integrated in that image. There is no need to install any additional software. All components (DB, mail server, web server etc,) are bundles within the VMware images and controlled by the internal LUCY software, which runs transparently in the background. The updating of those components is also done within the LUCY software through internal processes, which are not visible to the end user.
The list of supported browser and OS can be found here.
The hardware requirements may vary depending on the amount of recipients you upload for testing, your campaign type and also how you run the campaign. More info here.
LUCY offers different API's to third party services or via REST API:
Lucy can be installed on premise or in the internet. More info here.
LUCY may require certain communication channels to servers on the internet. More info here.
Starting from 4.3, LUCY is running on a 64-bit Debian 9 (Stretch) system. There are no system patches or hardenings applied - LUCY uses a vanilla Debian distribution without any additions. The system is configured to download updates and new packages from a custom LUCY apt mirror, which has the same IP address, as LUCY license server (make sure it is open on your corporate firewall). The operating system gets updated only when you upgrade LUCY to a new version.
There are a few accounts on the system like “phishing” or “support”. The “phishing” account is the one that is used for Lucy file permissions. Also you can SSH to Lucy using “phishing” account and it will automatically launch the console setup program. The “phishing” account is required for Lucy to function properly, so it's not recommended for removal. If you SSH to the “phishing” account the console setup program (python setup script) is launched (with elevated privileges). So it can't be used as a full-featured SSH login. The purpose is to only run the setup console.
The “support” account is used to log into the system over SSH when user turns on SSH access for support. It's safe to remove the “support” account, but then we won't be able to log into that system over SSH for support purposes.
Lucy web interface uses Apache 2.4 as a web server. The server utilizes “mod-security” and “mod_headers” modules to hide underlying software signatures from external visitors.
LUCY stores all related data in PostgreSQL 9.6 RDBMS. All sensitive information stored in there is encrypted as PostgreSQL is available only for internal connections. There are no configurable options for the DB encryption. The encryption is mandatory for all data and is performed automatically with the following settings:
LUCY also uses Redis Server 3.2 as an intermediary storage (task queue) when passing input data and results between users and background system workers. The data stored in Redis is not encrypted.
LUCY code is a PHP application based on Yii Framework. Certain parts of the system (some background scripts) are implemented using the Python programming language. We follow the following security principles:
Almost all LUCY files are located in /opt/phishing folder, which contains the system code, user files and settings. Normally, you shouldn't have to deal with LUCY code, so the most useful directories are those where user files are stored. All user-related files are placed in /opt/phishing/files folder:
There are several places in the system where you can find LUCY-related logs. They can be helpful to resolve or diagnose issues using your own technological resources without involving LUCY support. First of all, you should look at Apache web server logs directory /var/logs/apache2, where web server saves access and Error log files:
The next place with logs is /opt/phishing/runtime, where LUCY application logs are stored:
There are several system services that are critical for LUCY. You can check if they are running by executing “ps aux” command. If some of required services are not running, then they should be started using “service NAME start” command (where NAME is the name of the service you are going to start):
When Lucy is installed as a docker image, it gets downloaded from https://hub.docker.com (you can search for Lucysecurity there) to internal docker storage that is managed by docker itself – as any other usual docker image. Usually it’s /var/lib/docker/. After that the installer launches the image with specific parameters, extracts a management script (that launches Lucy’s console setup tool) to /tmp/files, moves it to /usr/bin/lucy-setup.sh and removes the /tmp/files folder. These are all changes that the docker-based installer does, all other software and files are within the container.
When installing Lucy in a “legacy” way (which is possible only for Debians, as the installer requires some Debian-specific packages and software versions), the installer adds around 500 new packages, does very deep system changes, including configuring the login shell, changing other services (postfix, apache, etc).
No, pre-installed docker engine is just fine and will work completely the same. Just make sure it will be updated on time.
When using a Docker-based installation, the Docker engine and all packages on the host are managed by the host package management system – be it RHEL package management or Debian/Ubuntu APT. Lucy’s docker container has no access to outer system and therefore cannot install any updates there. When using a “legacy” installation, all software packages are updated along with Lucy updates using Lucy's Debian mirrors.
After installing a Docker container with Lucy, Docker's container system is not involved anymore - all updates are performed within the container using container's APT system with our custom package mirror.
Lucy's container is downloaded from https://hub.docker.com (official Docker Hub) during installation.
In case of Docker installation, only software inside the container is affected. There are no consequences for the software on the host system. When using a legacy installer, the proxy configured will be used as a default proxy for the whole Linux system.
Speaking of Docker container installation, the backup is seamless and is a peace of cake. First of all you “commit” the container, making a static image of it with all files, changes, etc: docker commit lucy lucy-backup After that you:
The backup image can be recovered easily from file by docker load -I /path/to/lucy-backup.tar (in case of local file) or docker pull lucy-backup (in case of private docker registry)
After that you can start your container as a regular docker container with this command: docker run –privileged -v /proc/sysrq-trigger:/sysrq -d -p 80:80 -p 443:443 -p 25:25 -p 5001:5001 –name lucy –restart=always lucy-backup /bin/bash /etc/run-services.sh
Things get a bit more difficult in case of “legacy” installation - you should back up multiple directories, where configurations and files are stored: