Two accounts we did not recognize. What we found on an internet-exposed MikroTik

It started with a warning one of our clients received from their internet provider.

The connection had not gone down. The router was working, users had internet access, and there was no obvious sign from the outside that anything had happened. The warning did, however, say that some ports on the MikroTik router were reachable from the internet when they should not have been.

The configuration had been put in place before we took over management of the infrastructure, and there was no operational reason for those services to remain publicly exposed.

The first thing we did when we accessed the router was close off access that was not needed.

Then we began checking its configuration.

And we found two user accounts we did not recognise.

Both had full privileges on the router.

At that point, the problem was no longer just “we have some open ports”.

Two unknown accounts do not automatically tell you what happened

It is tempting to see two unknown administrative accounts and immediately conclude that the router was compromised.

We cannot establish that from their existence alone.

We do not know who created them, when they were created, or how. They might have come from an older intervention that was never documented. They might have had a legitimate explanation that we could no longer reconstruct.

But we could not ignore them either.

Two accounts with full privileges, on a router with services exposed to the internet and a configuration previously managed by someone else, were enough for us to stop treating the existing configuration as trustworthy.

In security, there is an important difference between “we know the system was compromised” and “we can no longer demonstrate that the system is clean”.

We were in the second situation.

Meanwhile, CERT Polska had published significant findings about RouterOS

The timing coincided with the publication of important vulnerabilities found by CERT Polska researchers in MikroTik RouterOS.

On 5 September 2026, CERT Polska published details of six RouterOS vulnerabilities. Two can be chained in an attack named MikroTrick, allowing an attacker to take full control of a device without authentication when the router's SSH service is accessible from public networks. CERT Polska also confirmed real-world attacks against RouterOS devices with SSH exposed to the internet.

The precise distinction between the vulnerabilities matters here. In its subsequent technical analysis, CERT Polska identifies CVE-2026-67279 and CVE-2026-86060 as the two flaws that make up the MikroTrick chain.

CVE-2026-67279 allows an SSH connection to advance to session handling without completing user authentication under particular rekeying conditions. On its own, it does not establish an authenticated identity or grant privileges, but it creates the condition needed for the second flaw.

CVE-2026-86060, rated CVSS 9.2 by CERT Polska, involves a specially crafted username and can give the resulting SSH session full administrative privileges. Combined with CVE-2026-67279, it forms the chain CERT Polska says has been used in attacks on routers accessible from public networks.

CVE-2026-67276, also rated CVSS 9.2 in CERT Polska's assessment, is a separate SSH public-key verification flaw. Under specific conditions, an attacker who knows the account name and the public modulus of its RSA key could authenticate without the corresponding private key. It is not one of the two vulnerabilities in the MikroTrick chain.

Another significant flaw, CVE-2026-67277, affects the bandwidth-test service and can allow fragments of memory to be disclosed or cause a system restart. The research was not limited to these flaws: CERT Polska also identified issues in other RouterOS components, including WebFig and X.509 certificate handling.

MikroTik published security updates and explicitly advised administrators not to allow SSH access from untrusted networks and, preferably, not to expose management interfaces directly to the internet at all.

Does this mean our client's router was attacked through MikroTrick?

We do not know.

And it matters that we say so.

The presence of two unknown accounts does not show that they were created through the vulnerabilities described by CERT Polska. We did not have enough evidence to connect the client's situation directly to MikroTrick, and we do not want to turn suspicion into certainty just because the two events fit neatly into a story. We also cannot establish from the warning alone that this router's SSH service was exposed.

CERT Polska published concrete indicators from the attacks it observed, including particular log entries and the appearance of a highly privileged user named ops. It also cautioned that the absence of those indicators does not prove that a device was not compromised.

For us, the relevant question was different.

Could we still trust the router's configuration enough to change two passwords and carry on?

Our answer was no.

An update fixes the vulnerability. It does not necessarily undo what happened before

We updated RouterOS to a version containing the security fixes.

That was necessary, but it was not enough.

If a system really was compromised before a patch was installed, the update closes the vulnerability an attacker might have used to get in. It does not automatically remove users, scripts, tunnels, or other changes made earlier.

MikroTik recommends checking the configuration after the update for unknown users, scripts, or other entries the administrator does not recognise. CERT Polska goes further: when there are reasonable signs of compromise, it recommends preserving the available evidence, resetting the device, rebuilding it from a configuration the administrator can trust, and then changing the passwords, keys, and other secrets in use.

In our case, we had already found the two unknown administrative accounts.

So we chose not to rely on the update alone.

From an unknown configuration to one we could trust again

We closed the management services that had no reason to be publicly available.

We changed the administrative account's password and updated RouterOS.

Then we performed a clean RouterOS installation.

The reason was simple: we did not want to continue administering a configuration when we could not say with confidence who had changed what before we took over.

At the same time, we started rotating credentials that might have been known to or stored on the router. We did not stop at the MikroTik administrator password. We also changed other credentials relevant to the infrastructure, including those associated with the connection provided by RDS.

If you consider that a network device might have been compromised, changing one password does not necessarily solve the problem.

The router may have access to other passwords, keys, VPN configurations, PPPoE credentials, or information you should not continue to treat as secret merely because you cannot prove it was read.

Rotating them was the prudent choice in this case.

Open ports are not the vulnerability, but they can make one matter

This may be the most useful part of the whole intervention.

An open port does not automatically mean someone can compromise your router. SSH, HTTPS, and other management services exist to be used.

The question is where they can be reached from and whether there is a real reason for them to respond to anyone on the internet.

For MikroTrick, that distinction is concrete: CERT Polska says the confirmed attacks targeted RouterOS devices whose SSH service was reachable from public networks. MikroTik recommends blocking access from untrusted networks and suggests using a VPN such as WireGuard for remote administration instead of publishing management ports directly.

That does not mean an updated, properly configured router can never have a service reachable from the outside.

It means that “do we need this port open?” should be a question with an answer, rather than a condition inherited from a configuration made years earlier.

What we took from the incident

We cannot say that we proved how the two accounts appeared.

Nor can we say that MikroTrick was used against our client.

What we can say is what we found: services that should not have been publicly exposed, and two accounts with full privileges that we could not associate with a known person or intervention.

In that situation, we chose to treat the router as a device whose integrity we could no longer guarantee. We limited its exposure, updated RouterOS, changed credentials, reinstalled the system, and rebuilt a state we could trust again. Decisions like these are part of our network and security work.

That is the less spectacular part of a security incident.

Often you never learn who got in, from where, or what they intended to do.

Sometimes you cannot even prove that anyone got in at all.

But you can decide how much uncertainty you are willing to accept in a device through which the entire company's traffic passes.

In this case, two unknown administrative accounts were enough for our answer to be: too much uncertainty to leave the configuration as it was.