Should I be concerned?

That depends what you mean by "concerned". If you mean, motivated to do some kind of more thorough audit to determine what process is responsible for this, then sure, why not. However, if you don't have a ready means of doing that, then I guess it depends on how motivated you are to find and use one (which could add up to "This is what I did on Saturday/the weekend/the first week of December..."); I would not bother unless that's something you are interested in for broader reasons.

A few points to consider:

• This is just a read of privileged information by a process that's obviously intended to be so privileged. That doesn't necessarily make it malicious.
• The information being accessed is pretty mundane (see man 5 shadow, and note that access to the "encrypted password" is not access to the password itself; passwords aren't actually stored anywhere, just a one-way hash of them, which is not useful except for verification).
• If someone wanted to be stealthy in doing this, this is not. However, that doesn't necessarily mean it isn't part of something malicious.

My guess is this is from some innocent but pi specific script. Raspbian is unusual in the unlimited superpowers it provides a regular user, so this methodology (grepping /etc/shadow via sudo) would be pointless on most GNU/Linux systems. If the process responsible needs to do this, then normally it would be run as a process with a UID that did not need to use sudo, so very likely it's written by someone who knows how Raspbian is put together (such as someone responsible for some piece of Raspbian specific software).

It is not hard to imagine "non-innocent" here too, but you might just as well speculate about that without this, i.e., with no evidence at all. If someone is out to cause mischief, there's nothing about reading /etc/shadow that points to it by definition. It could be argued that there isn't much purpose in restricting read access to that file anyway.

Should I be concerned?

That depends what you mean by "concerned". If you mean, motivated to do some kind of more thorough audit to determine what process is responsible for this, then sure, why not. However, if you don't have a ready means of doing that, then I guess it depends on how motivated you are to find and use one (which could add up to "This is what I did on Saturday/the weekend/the first week of December..."); I would not bother unless that's something you are interested in for broader reasons.

A few points to consider:

• This is just a read of privileged information by a process that's obviously intended to be so privileged. That doesn't necessarily make it malicious.
• The information being accessed is pretty mundane (see man 5 shadow, and note that access to the "encrypted password" is not access to the password itself; passwords aren't actually stored anywhere, just a one-way hash of them, which is not useful except for verification).
• If someone wanted to be stealthy in doing this, this is not. However, that doesn't necessarily mean it isn't part of something malicious.

My guess is this is from some innocent but pi specific script. Raspbian is unusual in the unlimited superpowers it provides a regular user,¹ so this methodology (grepping /etc/shadow via sudo) would be pointless on most GNU/Linux systems. If the process responsible needs to do this, then normally it would be run as a process with a UID that did not need to use sudo, so very likely it's written by someone who knows how Raspbian is put together (such as someone responsible for some piece of Raspbian specific software).

It is not hard to imagine "non-innocent" here too, but you might just as well speculate about that without this, i.e., with no evidence at all. If someone is out to cause mischief, there's nothing about reading /etc/shadow that points to it by definition. It could be argued that there isn't much purpose in restricting read access to that file anyway.

^{1. Horrible, misguided, absurd. One of the first things I do with a Raspbian install (sometimes, before I even boot it the first time) is remove the pi user completely and snip out most of the nightmare in /etc/sudoers.}