On September 14, Huntress discovered an emerging threat involving FOUNDATION Accounting Software, which is commonly used by contractors in the construction industry. Attackers have been observed brute forcing the software at scale, and gaining access simply by using the product’s default credentials. We're seeing active intrusions among plumbing, HVAC, concrete, and similar sub-industries.
How It Works
The FOUNDATION software includes a Microsoft SQL Server (MSSQL) instance to handle its database operations. While it is common to keep a database server internal and behind a firewall or VPN, the FOUNDATION software features connectivity and access by a mobile app.
For that reason, the TCP port 4243 may be exposed publicly for use by the mobile app. This 4243 port offers direct access to MSSQL.
Microsoft SQL Server includes a default system administrator account named sa, which has full administrative privileges over the entire server. Additionally, the FOUNDATION software looks to have created a dba account, which is not a built-in user, but Huntress has observed multiple instances where these high-privilege accounts are left with unchanged default credentials.
Because these accounts have such a high privilege, these administrator accounts can readily enable and leverage a feature known as xp_cmdshell within MSSQL. This is an extended stored procedure that allows the execution of OS commands directly from SQL, enabling users to run shell commands and scripts as if they had access right from the system command prompt.
-- Enable advanced options
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
-- Enable xp_cmdshell
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;
-- Run a shell command as an example
EXEC xp_cmdshell 'ipconfig';
How To Stay Protected
Since we're seeing attackers exploit publicly facing versions of the software using default credentials, we advise the following to mitigate this threat:
- Rotate all credentials for accounts connected to FOUNDATION's database, including dba and sa.
- This can be done within MSSQL with a command:
ALTER LOGIN sa WITH PASSWORD = 'NewStrongPassword';
ALTER LOGIN dba WITH PASSWORD = 'AnotherNewPassword';
- This can be done within MSSQL with a command:
- Where possible, cease exposing the Foundation application to the public Internet.
- Disable xp_cmdshell where appropriate.
How We Discovered the Threat
The Huntress SOC initially saw activity begin on September 14 at 15:38:35 UTC. What tipped us off was host/domain enumeration commands spawning from a parent process of sqlservr.exe.
Looking at commonalities among the affected machines, it was apparent that the attack was scripted, as the same commands spread out across several unrelated companies within a span of a few minutes.
For your own investigative purposes, the FOUNDATION software is typically installed at:
C:\Program Files (x86)\Foundation
with a subdirectory, ServerConsole3000, that contains its server component.
To examine the SQL database access, we saw the brute force attempts in
C:\Program Files\microsoft sql
server\MSSQL12.FOUNDATION\MSSQL\Log\ERRORLOG
where the version MSSQL12 may vary between MSSQL11, MSSQL13, MSSQL15, etc.
On one host we observed ~35,000 brute force login attempts against the MSSQL server ending just an hour before a successful authentication and enabling xp_cmdshell to run commands. It is evident in the logs:
2024-09-14 11:24:45.79 spid51 Configuration option 'show advanced options' changed from 0 to 1. Run the RECONFIGURE statement to install.
2024-09-14 11:24:45.81 spid51 Configuration option 'xp_cmdshell' changed from 0 to 1. Run the RECONFIGURE statement to install.
While the brute force attempts may be any scanner on the Internet, access to xp_cmdshell from just default credentials is a more severe issue.
Looking across the 3M+ endpoints that Huntress protects, we discovered ~500 hosts running the FOUNDATION software. From that pool, we confirmed that a sample of 33 hosts were publicly exposed with unchanged default credentials.
How Huntress Has Responded
As we typically do, we immediately isolate any machines where we detect suspicious activity while we investigate. At that point, we set out to identify the underlying cause for the suspicious activities. We also took measures to identify any potential detection capabilities.
In addition to notifying those where we saw suspicious activity, we also sent out a precautionary advisory notification to any of our customers and partners who have the FOUNDATION software in their environment. While we did not see any suspicious activity in these accounts, we wanted to ensure they take the precautionary measures we suggested above to reduce the risk of them being compromised in the future.
Special thanks to Tanner Filip, Michael Tigges, John Hammond, Jamie Levy, Alden Schmidt, Craig Sweeney, Dray Agha, and others for their tireless efforts and contributions to this investigation and writeup.
