What we find when we secure Greek shipping offices

Intellinet is an Athens managed-services and cybersecurity provider working mainly for ship-management companies: office networks, Microsoft 365 tenants, vessel IT and cyber-risk work under the ISM Code. This advisory sets out what we found while securing those environments between April and October 2026, and what stopped each problem.

Every case is anonymised. No client, vessel, person, domain or address is named, and timings are given only to the month.

1. Mailbox compromise: three cases, three different doors

All three cases ended in an attacker holding a working mailbox. None of them was stopped by SPF, DKIM or DMARC, because each attacker either signed in with valid credentials or arrived through a genuine supplier.

A supplier quotation that carried a remote-access trojan (September–October). A real, compromised mailbox at a European marine supplier sent a quotation-themed email to five mailboxes at one ship manager. The attachment was a .gz archive larger than the mail gateway's extraction limit. The gateway could not open it, rated it "unscannable" rather than malicious, and delivered it; its retrospective verdict flagged it malicious the next day. A user on a vessel extracted it on a shared remote-desktop server. A week later a Remcos dropper ran and stayed resident through a scheduled task. Stolen credentials were then used from abroad to sign in to webmail, add a forwarding address and attempt impersonation sends. We contained the mailbox, removed the persistence, quarantined the files and confirmed the root cause from gateway tracking.

A shared mailbox turned into a spam relay (August). A shared departmental mailbox had a password last changed four and a half years earlier, no MFA, and SMTP AUTH enabled across the tenant. Credential stuffing from 48 IP addresses in more than a dozen countries succeeded over two nights. The attacker then relayed spam through it for about ten hours. Nothing alerted; it was found because a staff member asked whether "we have a virus". We blocked sign-in, revoked tokens, disabled legacy protocols and rotated or blocked all 34 shared mailboxes in the tenant.

A mailbox read quietly for five days (July–August). A separate user mailbox in the same tenant was opened by webmail from one foreign IP address every four hours or so, for five days. No spam, no visible change. This is the pattern that precedes payment-diversion fraud, so the follow-up was a review of sent items and bank-detail changes, not just a password reset. We first assumed it was the source of the relay case. The sign-in evidence showed different infrastructure, different tradecraft and a three-day gap, so we treated them as two independent compromises of the same weakness.

What we took from these cases:

• Archives the gateway cannot scan should be quarantined, not delivered. "Unscannable" is not "clean".
• Shared mailboxes do not need to sign in at all. Blocking their sign-in removes the password from the attack surface.
• Legacy protocols (SMTP AUTH, POP, IMAP) bypass MFA and should be off by default. Before disabling EWS, check which applications use it: in one tenant a cloud backup product authenticated through EWS and never appeared in user sign-in logs.
• Microsoft Defender may automatically restrict a mailbox that sent spam. Inbox-rule redirects count as sending, so a desk that receives mail through redirects goes silent without an alert.

2. Credentials and admin interfaces left in the open

The second pattern is quieter: the keys to the most important systems sit where anyone with a foothold can pick them up.

Database administrator passwords inside application files (April). On one office's SQL Server, a line-of-business application kept the SQL sa password in plain text in an .ini file under Program Files. A second application stored the same class of credential "encrypted", with the key embedded in a DLL shipped with the product, which is plaintext in practice. Two further logins held sysadmin rights without a documented owner. A reporting component bundled with the software had been out of support for years. None of this was a breach, but any attacker with file-read access on that server would hold the whole database.

A router managed from the whole internet (September). At another office the edge router allowed web and SSH management from the internet on non-standard ports, with an empty access list, so any source address could try. TLS 1.0 and 1.1 were still enabled. Brute-force lockout was the only control.

What we took from these cases:

• Ask vendors whether their software supports Windows-integrated authentication or a dedicated, least-privilege SQL login. Where it does not, record the accepted risk and compensate with segmentation and file-access monitoring.
• Review every sysadmin login against a named owner. Demote what nobody can account for.
• Remote management of edge devices belongs behind the VPN. If it must face the internet, restrict it to known source addresses and turn off old TLS versions.

3. Microsoft 365 tenants: licensed for protection, configured for convenience

The tenants we assess usually already pay for the controls that would have stopped the cases above. They are simply not switched on.

One read-only assessment in October of a ship manager's tenant, about 80 active users on Business Premium, gives a typical picture:

Area	What we found
Microsoft Secure Score	45%, unchanged for a month
MFA for all users	Policy built but left in report-only mode
MFA registration	67% of enabled accounts; the 27 without it were shared, room and service accounts that could still sign in
Email authentication	No DMARC on any of 4 domains; DKIM off on 2 of 3 sending domains
Anti-phishing	User, domain and mailbox-intelligence impersonation protection all off
Endpoint hardening	0 of 17 attack-surface-reduction rules on the onboarded devices
Devices	1 of 26 Intune-enrolled devices compliant
Privileged access	5 Global Administrators, one a disabled account and one a vendor's service account with access to almost every mailbox
Stale accounts	31 enabled accounts unused for over 90 days
External sharing	Anonymous "Anyone" links allowed in SharePoint

In a second tenant, which suffered the relay case in section 1, the only Conditional Access policy was the one Microsoft creates by default. There was no MFA enforcement and no legacy-authentication block, the two controls that would have prevented both of its compromises.

What we took from these cases:

• Move "require MFA for all users" out of report-only and give it a short, owned exclusion list.
• Block sign-in for shared and room mailboxes, and block legacy authentication with Conditional Access.
• Publish DMARC (start at p=none with reporting) and enable DKIM on every sending domain.
• Treat vendor service accounts as privileged identities: no Global Administrator, scoped mailbox access, reviewed credentials.

4. Cyber chapters in the SMS: written, but not operable

Most ship managers we review have a cyber chapter in the Safety Management System, as IMO Resolution MSC.428(98) expects. Few of those chapters would let anyone run an incident or answer a vetting inspector.

We test each chapter against the six functional elements of MSC-FAL.1/Circ.3/Rev.3 (April 2025): Govern, Identify, Protect, Detect, Respond and Recover. Many manuals still cite the 2017 guidelines and their five-function model. One review in September found this:

Function	Finding
Govern	Not established: the accountability chain contradicted itself, with no targets or oversight cycle
Identify	Asset catalogues present, but no risk method, no asset owners, and demonstration data in the inventories
Protect	Controls asserted in the present tense but not evidenced; no MFA requirement
Detect	Human observation only; no sign-in logging; log retention never mentioned
Respond	Empty contact table, a missing flow chart and four contradictory reporting routes
Recover	Referred to IT, with no recovery time or point objectives, no offline backup and no restore test

The gap matters commercially as well as at the DOC audit. Dry-bulk vetting under RightShip RISQ asks for appointments, asset inventories, awareness records, drills and an incident procedure, and DryBMS rates maturity on the track record. Prose alone scores low. Greek Law 5160/2024, transposing NIS2, also brings transport into scope with incident-reporting deadlines and accountability that reaches management personally.

What we took from these cases:

• Write Govern first: who owns cyber risk, who accepts it, and how often management reviews it.
• Replace prose with records: a scored risk method, pre-scored risk assessments per vessel, numbered forms and a drill log.
• Keep a one-page conformance matrix (requirement, clause, record). It answers an inspector in one page and turns the annual review into a check rather than a rewrite.
• Have the assessment done by someone other than the party that runs the systems.

5. Vendor software: the same secret in every installation

Office hardening only goes so far when the applications themselves carry the weakness. In 2026 we examined two commercial applications used by shipping companies, working only from their publicly distributed installers. No customer system was tested.

Both showed the same class of design flaw:

• Secrets that are identical across every installation: in one product an administrator credential, in the other the encryption keys that protect stored passwords. One copy of the software is enough to unlock the same secrets at every customer site.
• Bundled third-party components several years out of date, with publicly known flaws, reachable over the network in the default setup.
• Customers' own credentials for other services stored in plain text or in a reversible form.
• Update packages that left all of the above unchanged.

Product details are withheld. The same precautions apply to any line-of-business software:

• Ask the vendor whether credentials and encryption keys are generated per installation, and how you rotate them.
• Allow network access to an application's database only from the machines that need it.
• Give vendor software its own limited mail account for sending, never a staff member's or a departmental mailbox password.
• Keep vendor applications in the asset inventory and the risk assessment, with an owner and a review date.

Checklist for a shipping office

Ten checks, in the order we would run them. Each one would have prevented or shortened a case above.

1. MFA enforced for every user, not in report-only mode.
2. Sign-in blocked for shared, room and service mailboxes.
3. Legacy authentication (SMTP AUTH, POP, IMAP) blocked, after checking which applications still depend on it.
4. Archive attachments the gateway cannot scan quarantined, not delivered.
5. DMARC published and DKIM enabled on every sending domain.
6. Forwarding to external addresses alerted on or blocked.
7. Every Global Administrator and sysadmin login tied to a named owner; vendor accounts scoped down.
8. No database or admin passwords stored in application files; edge-device management behind the VPN.
9. Cyber chapter rewritten on the six Rev.3 functions, with Govern first and a conformance matrix.
10. Backups restored in a timed test, with stated recovery time and point objectives.

About this advisory

Published by Intellinet MSP EE, Athens. The findings come from incident response, Microsoft 365 tenant assessments, SMS reviews and vendor-software analysis carried out in 2026, published with all identifying details removed. It describes what we found and what we did; it is not advice for your specific environment and makes no guarantee of outcome (see our terms).

Questions or corrections: info@intellinet.gr. Reference: IMO — Maritime cyber risk (Resolution MSC.428(98) and IMO's cyber risk guidelines).