New Zealand Company’s ‘Impossible-to-Hack’ Security Turns Out to Be No Security at All
Teammateapp.com had a publicly exposed database and told me to stop harassing them after I emailed them about it.
What is Teammate App?
“Beautifully Designed, Easy to Use
Comprehensive Software Solution for implementation & maintenance of ISO Standards and other Compliance Requirements such as H&S, Quality, Environmental, Food Safety, Information Security and many more.” according to their website.
For those curious about what the company offers, you can check https://teammateapp.com/features, a special mention to the feature below:
Another good page to understand the claimed security of Teammate App can be read here: https://teammateapp.com/security-policy
Finding the exposed ‘Database Sizes’
On February 11th 2025 I was looking at some servers running exposed databases publicly and noticed a server with almost 200 tables exposed that contained some interesting names.
After a quick look I wasn’t exactly sure who was responsible for the server I was looking at and I was busy with other things so I flagged it to check later and a couple days later I took a better look and through DNS records and data on the exposed tables I confirmed it belonged to https://teammateapp.com and it was one of their live databases.
I checked my logs to see when was the first time I had this flagged as exposed and the first result was from December 3rd 2024.
Notifying Teammate App
On February 15th I sent an email to multiple emails from the CEO that were exposed on the database, his personal Gmail and a company email for https://kaizenconsulting.co.nz which according to public records he also owns and had a lot of data exposed here. I also added a couple of Teammate App emails listed on their website.
The first phrase on that email states the following:
" First of all, please do not ignore this email, this is not a scam attempt nor am I trying to sell anything, I am just alerting and looking for help closing down a security issue related to https://teammateapp.com/ "I have been adding this phrase to the start of my emails recently because companies assume my emails are either scam/phishing attempts or I’m some cybersecurity vendor or whatever trying to sell them some service or product and often ignore my alerts because of it.
The email was read by someone, I assume the CEO, and less than an hour after it was sent, I could not connect to the exposed server anymore. I did not get any reply back so a few days later I sent a follow up email.
On this email I asked the usual questions I do on my follow ups such as intent regarding notifications, if the company needed me to delay my publication to give them more time to notify anyone and if they wanted to provide an official comment to add to this publication.
A couple days later I got a reply that is both highly inappropriate and laughable at the same time.
‘Impossible-to-Hack’ Security
Teammate App CEO, Sean Banayan, who has the reading comprehension and IT knowledge of a toddler, decided to reply the following:
Apparently alerting him about a severe security issue with his App and sending a follow up email to try to avoid publishing anything before the company had time to do their own notifications, if that was their intent, means I’m harassing the company.
Sean was not interested in anything I was selling either (I don’t sell anything and state exactly that on my first contact) and even threatened to stop me if I didn’t stop with the harassment.
He was also kind enough to lie and claim “There were few more security layers which would have made any data breach impossible anyway.” and only basic information such as database sizes was exposed.
The email ended with a “Get it??” and in light of his demand that I allegedly stop harassing him and his obvious cluelessness about the security of his own data, I did not reply to that email. The remainder of this post will demonstrate how wildly inaccurate his claims were.
Security layers that don’t exist
The next part might come as a shock, to no one, but companies just tell whatever bullshit serves them best, not only to me but to their clients as well, this is a common occurrence.
Let’s see what “exposed basic information such as database sizes” really means.
The exposed sizes
Top 30 exposed tables in terms of record counts:
715,090 formfieldhistories 351,007 auditquestioncomments 348,542 dailymaillogs 139,419 formfields 106,454 employeeskills 100,915 auditformsectionquestions 98,843 formsubmissions 90,901 documenthistories 90,571 tasks 81,259 documents 80,680 auditscores 50,597 formfieldauditlogs 48,510 risks 48,079 activityloggers 47,409 audits 36,416 auditformsectionscores 27,245 hazardous 25,056 formtemplateauditlogs 23,766 plants 23,518 formtemplatehistories 23,279 employees 20,179 documentacknowledgements 20,131 employees_16_1,012024 17,202 auditformsections 16,719 reassignownerships 16,641 suppliers 16,506 vismatelogtimes 16,474 users 15,413 employeeassisgnonlinetrainingforms 15,126 personnels
The full table list and sizes can be seen here: https://pastebin.com/8q7CNYBi
The database contained a total of 2,963,124 records of exposed data, using around 3.8GB of storage.
If what Sean wrote to me was the truth, the post would be about done here. In reality it wouldn’t even exist, why would I waste my time reporting exposed database sizes and table counts?
So let’s analyze some of the tables exposed and the data in them.
formfieldhistories - 715,090
This was the biggest table in terms of records on the DB and didn’t contain any relevant PII that I was aware, it was the updates made to the fields of the various forms companies have on the app. I saw a few links to actual filed forms on some tables and I could check them with no authentication, but I did not look much into it though.
users - 16,474
This table contained usernames, emails, auth tokens and passwords. Around 9,000 users had bcrypt hashed passwords and around 6,000 had auth tokens set.
This also contained multiple foreign keys to other tables on the database with more information on the users such as companyId, employeeId, supplierId, etc.
The top 20 email domains exposed on the user table and their counts:
651 awanuilabs.co.nz 542 labtests.co.nz 527 sclabs.co.nz 368 wellingtonscl.co.nz 292 jasmax.com 246 gmail.com 137 kaizenconsulting.co.nz 132 medlabsouth.co.nz 129 gribbles.co.nz 126 awanuigroup.co.nz 114 snell.co.nz 103 culham.co.nz 100 nz.rlb.com 98 wadegroup.co.nz 74 tigerturf.com 66 cmp.net.nz 64 zeagoldnutrition.co.nz 62 taranakipath.co.nz 62 norpath.co.nz 58 teammateapp.com
A full count of the email domains can be seen here: https://pastebin.com/6L4hb2wL
employees - 23,279
This contained fields such as first and last name, company and workplace foreign keys, email, phone and mobile, date of birth and a field with additional information such as medical recommendations. There were multiple other tables related to employee data such as “employeesppes” which contained PPE (Personal protective equipment) information, mostly uniform sizes.
Top 20 email domains on the employees table:
3281 gmail.com 642 awanuilabs.co.nz 616 mediaworks.co.nz 607 labtests.co.nz 596 sclabs.co.nz 454 hotmail.com 398 wellingtonscl.co.nz 312 jasmax.com 298 yahoo.com 209 morganprojects.co.nz 206 xtra.co.nz 174 vnpf.com.vu 173 culham.co.nz 151 kawekahealth.nz 146 medlabsouth.co.nz 144 awanuigroup.co.nz 138 tranzit.co.nz 138 page-macrae.co.nz 135 gribbles.co.nz 123 outlook.com
A full count of the email domains can be seen here: https://pastebin.com/5vgz1JKq
documents - 81,259
This table if looked at briefly, probably wouldn’t mean much. There are no actual documents exposed on it, it contains partial paths, filenames, notes and information on who the file belongs to etc through multiple foreign keys to other tables.
Checking the companyId foreign key to check the companies with most records on the table we get the top 10 being:
15956 - https://www.cmp.net.nz 7568 - https://www.wedgelock.com 5501 - http://www.macrennie.com 4279 - https://www.kawekahospital.nz 3689 - https://tigerturf.com/nz 3590 - https://clearair.co.nz 3067 - https://glowlab.co.nz 2617 - https://solo.co.nz 2308 - https://maxion.co.nz 1603 - https://multifit.co.nz 1444 - https://www.nelsoncoachlines.co.nz
The counts are only for a single ID, if a company had multiple IDs the file count would be higher all put together, I did not look for such cases.
I was told about multiple security layers who made a data breach impossible, so of course I had to dig through this table until I found a way to test if the files were actually secure and I guess some layers were currently malfunctioning, as expected, I could actually download the files without any authentication.
The download link still redirected me to https://my.teammateapp.com/login but a request still went through for the file if it still exists in storage. From a small sample, around 75% of the files still exist and can still be accessed without any authentication or login.
The links still work as of publishing this, people would still need to know exactly how to get the working link but the company exposed that publicly for 2 months, who knows how many people got access to that information.
The sample contained files such as:
email communications(.msg files), incident reports, site induction questionnares, drivers licences, customer complaint reports, job safety analysis sheets, service reports, workplace safety checklists, job hazard analysis, tool box talk reports, field information reports, consumer feedback spreadsheets.
There were multiple more file types but I have no interest in downloading around 60,000 files just to prove a point.
The server IP was scanned by multiple websites that scan for open ports, I noticed it on at least 2 different websites.
Was anyone looking at the logs to see random IPs connecting and querying for “basic information” for over 2 months? What else were people doing that this supposed security layers missed? I’m sure the company has an answer for that.
Final comments
There is likely more data exposed here, this post only reveals a small sample of what was exposed but I can’t dedicate all my free time to analyze it and I’m not interested in doing an in depth security audit on the exposed data to a company who told me not to harass them.
This post serves to refute the claims of ‘Impossible to hack security’ made by Sean and if you’re a client or employee that uses the App, you might be wondering what else was exposed here. I would tell you to contact Sean or the company for clarification, but be wary you might be “harassing” them if you ask any questions.
To Sean Banayan
I bet it felt really good and mighty sending that email shitting on me as if I’m some random idiot begging people to buy something, but some advice for you, next time maybe use google to look up what ProtonMail is before claiming you’re gonna report me to my “boss” Proton, but thanks for the laughs on that one.
Also maybe read what I wrote on my email where I mention I’m not selling anything to you, in fact I alerted you of some gross incompetence, free of charge and likely avoided your data from being wiped by some russian running an automated script that wipes everything it connects to, I’ve seen it happen live before on the same service this data was exposed.
You might read this post and think that now you are for sure reporting me to my “boss” but you’ll be disappointed to know that I do not work for anyone, so you can’t go and harass my “boss” with stupid claims.
Those database sizes sure did contain a lot more than just the size, oops.
And one last thing Sean:
If you’re interested in more incidents I dealt with, you can check all my public finds indexed by country on the post below:
